Originally posted by: SystemAdmin

[MJEber said:]

Good Afternoon.

My background has been in compiler development before moving into consulting development.  I was writing an expression as follows:


dexpr float TravelProfit = sum (i in TravelTrips, s in shipData, c in Demand : i.customer == c.customer && i.material == c.material && i.ship==s.name)
i.capacity*c.rate*x[i] - (i.loadStart+i.unloadEnd+i.arrive-i.depart)*s.rate*x[i];


In any IDE work and compiler work I've done this statement would have properly parsed.
However in the OPL IDE it reports that in the second half of the equation (i.loadStart+i.unloadEnd+i.arrive-i.depart)*s.rate*x[i]  the variable i does not exist.
The only workaround I came up with that actuall allowed it to work was this:


dexpr float TravelProfit = sum (i in TravelTrips, s in shipData, c in Demand : i.customer == c.customer && i.material == c.material && i.ship==s.name)
( i.capacity*c.rate*x[i] - (i.loadStart+i.unloadEnd+i.arrive-i.depart)*s.rate*x[i] );


It seems like a parser bug to me.
#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: SystemAdmin

[alain.chabrier said:]

It does not look like a bug to me but  may be I miss something.

You write :

sum(i in set) f1(i) + f2(i);

If you look at precedence of operators in :
ILOG OPL Development Studio 6.1 > Language > Language Quick Reference > Appendices
You can see that
Aggregate sum, max, min, union 
is before
Binary +, -, union

and hence it can be re-written as :

(sum(i in set) f1(i)) + f2(i);

and then in f2(i) the i is unknown, so the error message that i is unknown.

If you want to force other operator order, you can use you other formulation :

sum(i in set) (f1(i) + f2(i));

then i is known.

Alain
#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: SystemAdmin

[MJEber said:]

from a language parser point of view here is why it is a bug:

Breaking the statement down into simpler terms you have

sum( item in Data [: {condition}] ) a*b*c + d*e*c [ comparator ]  | [] is optional data

From this statement: presedence should be applied only to the summation statement, not the total sum statement.  Thus presedence should be applied only to the statements after the sum() statement.  The comparator becomes the point where presedence application stops, since it no longer represents a mathematical presentation of data, but rather comparator data.

The presendence order that you suggest should only be applied if the parser encounters a new aggregate statement.  In a parse tree you would then have

                  sum            < -- top of parse tree<br />                  +              < -- next level of parse tree<br />        a*b*c        d*e*c  < -- multiplicand level of parse tree<br />

Now if it is written as follows

aggregate( d in collection ) d*b*c + sum( f in collection ) d*e*c

you now have precedence in the parse tree that should create the error as long as I don't override the precedence order.  In this case it is correct by your statement that in the second set of data, the variable d is undefined since it is in a new logic layer of the parsing tree.

That is why it is a bug.  (speaking pure parsing tree logic)
#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: SystemAdmin

[alain.chabrier said:]

MJEber,

of course, with the way you draw the parser tree it would be a bug.
But the parser tree construction is done based on the precedence order choices.

Given the precedence orders defined in OPL, see the link to OPL documentation given before, then the tree is :


        +
sum      d*e*c
a*b*c


Of course, each language and hence parser can use different precendece orders. Some might feel more easonnable or not depending on the usage context.


Think for a moment we would have chosen in OPL the inverse order, where the aggregate sum would have a much lower precedence order.

Then in a constraint like :

sum(i in S) x[i] + y <= 2;<br />
it would correspond to
sum(i in S) (x[i] + y) <= 2;<br />
and hence be different to

y + sum(i in S) x[i] <= 2;<br />
which would be quite difficult to understand.

Alain


#DecisionOptimization
#OPLusingCPLEXOptimizer