ILOG OPL cannot distinguish apples from oranges

I used to think about OPL that promotes obligatorily mathematical rigor as one would expect from a mathematical modeling language. I was misunderstood: it seems that OPL deludes itself when comparing apples and oranges. OPL still requires enhancements that address serious idiosyncrasies how the model is handled.

Objectives

The article presents some OPL examples for expressions that do not satisfy type safety. It additionally relates possible error messages.

The Apple and Orange model

Let consider the following “Apple and Orange” model. It does nothing very useful, but is reveals the issues to be discussed. The model defines two kinds of fruits: apple and orange. There is also a set of each fruit and a pair of expressions that perform some arbitrary calculation for each fruit. At last, there are some constants to refer to an arbitrary apple and orange.

Suppose the constants are used as indexes for the expressions, but they were exchanged by mistake. They are not anymore tuples from a domain defined for each expression. OPL counterintuitively accepts the model and proposes a wrong solution generated from cplex.

subject to {
orangeSum[oneApple] <= 10;
appleSum[oneOrange] <= 10;
}

However, this behavior is not consistent if one top level expression relies on another bottom level expression. In the following example, indexes are still exchanged by mistake for the top level expression. Opposed to the previous example, the model is rejected with a not so meaningful error message: Exception from IBM ILOG Concert: IloEvalIntTupleCellExprI::normalize.

The next example has correct indexes for the top level expression. But the referred bottom level expressions are exchanged by mistake. As consequence, the bottom level expression receive incompatible indexes in a identical manner as for the first example. While one would expect the same inconsistent behavior as in the first example, OPL now accuses the error with the same message from the second example: Exception from IBM ILOG Concert: IloEvalIntTupleCellExprI::normalize.

Even though syntactically and grammatically correct, OPL does not accept declaring a top level expression with a tuple index and that references a bottom level expression indexed by a tuple pattern. The observation is really annoying: OPL will reject both the (theoretically) correct and the mistaken model. Therefore, it was not possible to test type safety.

If any of the previous examples happens with formal parameters, the behavior is different, again. At least, OPL detects that there is somewhere a tuple attribute which name does not match with the expected tuple columns: Exception from IBM ILOG Concert: The column does not exist in the schema: a.

OPL is a valuable tool to describe mathematical models for linear programming and constraint programming since it allows to express a model in very concise but powerful way. However, the model generation is not sufficiently rigorous nor predictable if there are expressions or variables indexed by tuples. The OPL model generator may reject declarations that are apparently correct. Or it may accept declarations or constraints where indexes are from incorrect domain. OPL still requires enhancements that address serious idiosyncrasies how the model is handled.

Share this:

Like this:

Related

One Response to ILOG OPL cannot distinguish apples from oranges

Hi Daniel,
I’m in a research group in Melbourne who have developed a successor to OPL that is called Zinc.http://g12.research.nicta.com.au/zinc_current/index_home.php
It seems to avoid the problems revealed by your examples here.
The focus of Zinc is flexibility of mapping it to (combinations of) underlying solvers including Cplex but also Coin solvers, constraint programming solvers, SAT and SMT solvers, etc.
(We would welcome any publicity about our work, if you find it interesting and worthwhile!)