Menu

Submit a (potential) bug + questions related to Min/Max

2012-06-01
2012-06-01
  • Jean-Noël Monette

    Hello,

    I would like to submit what I think is a bug but it looks like there is no way to add a ticket in the bug section.

    Anyway, this is in the MinMax.scala file. You compute the values MyMin and MyMax, using the symbol "<", but I think that you should use the function "Better" in MiaxLin, or use the value of "Ord" in Miax. (I haven't check the other classes below.) Otherwise, this is correct for the Max invariant, but not for the Min invariant.

    By the way, I'm not an expert in Scala, but why don't you declare those methods (MyMin and MyMax) as "override". I though it was mandatory if you override a method of a parent class?

    Also, why Miax and MiaxLin are defined over a SortedSet of IntVar, and not just a List/array? I was looking at those classes because I would need a min/max invariant but where I would like to add the elements over which I compute the min or max one after the other. I was hoping that using a SortedSet as parameter would allow me to do it, but as I understand it, it would not work.

    So I was thinking of extending e.g. MiaxLin, and adding a method to add an input variable. But if understand well, I cannot add a static dependency after the finishInitialization(), which in turn must come before the call to setOutputVar. So is there a simple way to achieve something like:

    val maxInv = MaxLin(x1);
    y <== maxInv;
    maxInv.add(x2);
    maxInv.add(x3);

    instead of

    y <== MaxLin(SortedSet(x1,x2,x3));

    Thank you very much for your help,

    JN Monette

     
  • Renaud De Landtsheer

    MyMax and MyMin are actually the range of the output variable of the invariant. This is a mechanism that is proposed for IntInvariants and IntSetInvariants. Using this comparison symbol is tehrefore correct, as it is not influenced by the implementation of MiaxLin


    About the override, you are right, it is corrected, and comitted to the SVN, thank you :-)


    About why MiaxLin uses a SorteSet, you are right as well, I am removing all these, and putting iterables instead, or arrays. SortedSets are defined at the scala level, so you cannot modify the SortedSet after the invariant is created.


    At present, it is not possible to do this using the Miax or MiaxLin. Instead, I suggest you have a look at the ArgMaxArray and ArgMin Array. They not only output the ArgMax/ArgMin, but also the Max/Min (see getMax and getMin methods), and they take two parameters: an array of IntVar, on which they compute the Miax and ArgMiax, and an IntSetVar, which specifies the indexes of the IntVar to be considered in this invariant. To do wat you want, you rather add/remove values to this IntSetVar.


    By the way, in Asteroid, IntInvariants are automatically converted to IntVar if needed (using MyMin and MyMax of the IntInvariant), so you can also write:

    val max:IntVar = MaxLin(SortedSet(x1,x2,x3));
    
     

    Last edit: Renaud De Landtsheer 2012-06-01
    • Renaud De Landtsheer

      I forgot to mention MaxArray and MinArray. They do min/max they way you want. they take an additional IntSetVar which caputes the set of indexes to consider in the Min/Max.

       
  • Jean-Noël Monette

    Hi again,

    Thank you for the rapid answer! For ArgMaxArray, I had a look at this also, but it would require me to know beforehand the set of all variables that would be potentially involved in the Max. Anyway, I found another way to do it: collecting all the variables in a SortedSet, and only posting the Invariant just before closing the whole model. In fact, this is no more complicated ;-)

    Regarding the MyMin and MyMax, I still feel that there is a problem to compute them... If I understand correctly, MyMin and MyMax must bound the range of possible values for the output variable. So, imagine we compute the min or max of x1 which has a range of possible values in 1..5 and x2 in 6..10. Clearly the possible range of the output variable will be 1..5 if we look for the min, while it will be 6..10 if we look for the max. So they cannot be computed the same way. They might be computed the same way, if you approximated the output range to 1..10, but this is not what is done either, as in both case, you would return 6..10. Am I missing something?

    Cheers,

    JN

     
  • Renaud De Landtsheer

    Oops, you are right. This is corrected in [r48] with correct bounds. Better bounds will be added soon.

     

    Related

    Commit: [r48]

  • Renaud De Landtsheer

    Better bounds are computed in [r49]

     

    Related

    Commit: [r49]

  • Renaud De Landtsheer

    Corrected again (thank you Jean-Noël) in [r50]

     

    Related

    Commit: [r50]

Anonymous
Anonymous

Add attachments
Cancel





Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.