Originally posted by: SystemAdmin

I just want to use a variance as the object:
//////////
minimize (sum(t in 1..T) pow(Pd[t]+(sum(k in 1..N0) X[k][t])-(sum(i in 1..T) Pd[i]+(sum(j in 1..N0) X[j][i]))/T,2)/(T-1));
//////////
but the error message reads:
name "i" does not exist.

Why? is it that there is too nests？

the equation that I used above is enclosed as a picture.
#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: SystemAdmin

Is there some reason to \bar{P}_d needs to be embedded? It would seem to vastly improve readability to create a variable for this, create a dedicated constraint that sets this variable to the correct value and then include this variable in the objective function.

Troubleshooting and readability go hand-in-hand, no? Make it more readable and the problems tend to become more apparent. You're not likely to go back afterwards and say "this whole thing has too many variables let me squash them back together", but you could do that if you wanted, once you had something working.
#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: SystemAdmin

Thx for your reply.
I agree with your opinion,but I haven't found a way to do that. Most objectives is written in only one line,could you show me how to " create a dedicated constraint that sets this variable to the correct value and then include this variable in the objective function" ? I'am a green hand.
#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: SystemAdmin

Re: green hand ... no worries. I am coming up to speed on the details of OPL but have lots of experience troublshooting MIP/LP in general. So it is easier for me to explain with a .lp example than with OPL code, but the principle is exactly the same.

Suppose I had a model like

---

Min
obj:
1.5 UnitsProducedCleveland + 2.1 UnitsProducedNewYork +
2.3 UnitsShipClevelandToPortland + 0.9 UnitsShipClevelandToBaltimore +
4.1 UnitsShipNewYorkToPortland + 0.8 UnitsShipNewYorkToBaltimore

Subject To
"bunch of constraints"

---

So in the objective function the first line is the cost of production, the second and third lines are the cost of shipping.

You could easily rewrite this model as

---

Min
obj:
CostOfProduction + CostOfShipping

Subject To

CostOfProductionConstraint:
1.5 UnitsProducedCleveland + 2.1 UnitsProducedNewYork - CostOfProduction = 0
CostOfShippingConstraint:
2.3 UnitsShipClevelandToPortland + 0.9 UnitsShipClevelandToBaltimore +
4.1 UnitsShipNewYorkToPortland + 0.8 UnitsShipNewYorkToBaltimore

• CostOfShipping = 0

"bunch of constraints"

---

The second model is in general easier to trouble shoot. For example, if you're expecting the cost of production to be reasonably close to the cost of shipping, then the second model will let you verify that result much more easily.

CPLEX won't get hung up on these "extra variables" as a rule. CPLEX has a good pre-processor that simplifies them away. If you make 1,000,000 variables, and 800,000 of them are dummies, then perhaps you're overdoing it, but otherwise add the extra variables and constraints you need to make the model easy to read. Getting the correct results is the most important thing.

So in your example you could create a variable called PdAverage, then have a constraint somewhere in your model that was like

PdAverage - (sum(i in 1..T) Pd[i]+(sum(j in 1..N0) X[j][i]))/T = 0;

and then your objective function would be

minimize (sum(t in 1..T) pow(Pd[t]+(sum(k in 1..N0) X[k][t])- PdAverage ,2)/(T-1));

The part of the objective function that I called PdAverage is exactly the same for every t. So life will be easier if you pull that out and compute it in a dedicated variable.

Also perhaps the name PdAverage doesn't make sense. It seems like you're doing a big more there than just taking the average of Pd. Feel free to come up with longish variable names that are easy to read and describe things with some accuracy. A variable name that is 15-20 characters long would be ok for a tricky concept, and easier concepts can get shorter names.

And finally, even if you go overboard and decide you've made too many dummy variables, it's always easier to take a model that is working and gets correct results and rewrite it to be less verbose than it is to debug a really messy model that just isn't working.

Does that make sense?
#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: SystemAdmin

This forum is messing up the resolution of my response but obviously there is supposed to be a minus sign in the code that says "- CostOfShipping = 0"
#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: SystemAdmin

Exactly！I just feel the syntax of OPL is a bit too stiff, I'm used to programming with C.Your way is very simple but clever.
Best regards.
#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: SystemAdmin

:)

I have written code in lots of languages. I'm becoming a big fan of OPL, it has a very nice way of representing mathematics in ASCII, which is not easy. But you have to read enough of it to get used to it ... not very different from LaTeX ... after reading it a bit you stop needing to see it rendered, so long as the equations aren't too complex. And with MIP you can just use dummy variables so that none of the equations are too complex.

But this trick is really just good hygiene for MIP/LP, you can use in with any API.

So if you do this to your model does it work? I couldn't find a flaw in your original equation, but this will hopefully fix it or give you a better clue.
#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: SystemAdmin

Hello,

the part of your formula
sum(i in 1..T) Pd[i]
starts and ends the scope of i.
It does not exist for X[j][i]

Regards,
Zahar
#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: SystemAdmin

I don't think that's the problem.
In fact,after I changed the equation from:

minimize sum(t in 1..T) pow(Pd[t]+sum(k in 1..N0) X[k][t]-sum(r in 1..12) (Pd[t]+sum(s in 1..N0) X[s][r])/T,2)/(T-1);

to:
minimize sum(t in 1..T) pow(Pd[t]+sum(k in 1..N0) X[k][t]-*(*sum(r in 1..12) (Pd[t]+sum(s in 1..N0) X[s][r])*)*/T,2)/(T-1);

It works well then.

The debug advice provided by PeteCacioppi is quite useful.

Best Regards
#DecisionOptimization
#OPLusingCPLEXOptimizer

Originally posted by: SystemAdmin

To be clear, Linus's law states "given enough eyeballs, all bugs are shallow", and PeteCacioppi's corollary states that "given enough dummy variables, most MIP bugs are shallow".

There is no contradiction here.

So in this case, I believe Zahar is correct, there is a scoping problem indicated with the <<< >>> below.

minimize (sum(t in 1..T) pow(Pd[t]+(sum(k in 1..N0) X[k][t])-<<<(sum(i in 1..T) Pd[i]+(sum(j in 1..N0) X[j][i]))>>>/T,2)/(T-1));

If you look at just the bracketed section, the scoping of i doesn't carry all the way through. The second sum in the brackets shouldn't know about the i, because the sum over i terminates with the Pd[i].

I suspect that when you pulled this section out and used a dummy variable like I suggested, you must have added some additional parenthesis to fix this, perhaps inadvertantly... (no?).

At any rate, the original obj function was very messy, and simplifying it makes it simpler and easier to troubleshoot. There is no penalty to doing things this way, as a rule, and then you can ask for help for only the really thorny problems. (As opposed to the thorns that are self-inflicted).

Cheers
#DecisionOptimization
#OPLusingCPLEXOptimizer