[Coin-discuss] Osi redesign

[Mikhail Nediak]

Hi,

I think there was also a proposition to separate model components from the
solver. This a nice way to think about new design from the methodological
point of view. Also, this would allow us to incorporate different types of
models and solvers into the same framework in the future.

> The whole class structure should be very hierarchical with the constraint
> types and objective types on the bottom:
> OsiLinearConstraint, OsiLinearObjective, OsiQuadraticObjective, etc.
> These classes define the constraint structure and the objective structure and
> define how to modify them.
We could define abstract classes OsiObjective and OsiConstraint and then 
class OsiLinearObjective : public OsiObjective
class OsiQuadraticObjective : public OsiObjective
class OsiLinearConstraint : public OsiConstraint
class OsiIntegralityInfo : public OsiConstraint

One could, in fact, think of OsiVariable class instead and store domain
info such as bounds and integrality with it, but I am not sure it is a
better solution.
 
> >From these one can piece together other classes:
> class OsiLP : public OsiLinearConstraint, public OsiLinearObjective;
> class OsiQP : public OsiLinearConstraint, public OsiQuadraticObjective;
> These classes contain what can be done with an LP; most likely, it'll be the
> solve() method :-).
There could be a class OsiModel instead that would include a set of
OsiConstraint's and OsiObjective by composition as opposed to inheritance.

> If there are possibilities for further specialization then further classes are
> created:
> class OsiLPSimplex : public OsiLP;
> class OsiLPBarrier : public OsiLP;
> class OsiLPVolume : public OsiLP;
These guys would, instead, inherit from an abstract OsiSolver that takes
OsiModel as an input. When handed in model components that they can't
handle, they would through an exception.

> class OsiLPSimplexPrimal : public OsiLPSimplex;
> class OsiLPSimplexDual : public OsiLPSimplex;
> 
> Along these inheritances each class would declare only those methods that any
> object of that type should know. Say, getting a row of the tableau works for
> both primal and dual simplex, but getting a primal ray not necessarily. Many
> (if not all) of the methods will be pure virtual.
> 
> Finally the implementation is done on the top creating nice diamonds in the
> inheritance tree:
> OsiCplex : public OsiLPSimplexPrimal,
>            public OsiLPSimplexDual,
>            public OsiLPSimplexBarrier;
Something like this would still work with approach outlined above.

> The trouble comes when we want to do a solve() method, or getting the solution
> or anything that is defined in multiple classes. If several parallel class
> defines a solve method how will it be decided which solve is used? There are
> three possibilities: 
> 1) There should not be no name clashes, and call the mthods
>    solveSimplexDual(), etc.
> 2) We don't care about name clashes and if the solve method is invoked it has
>    to be specified which one we want. E.g.:
>       OsiLP* solver = new OsiCplex;
>       /* at this point all we know about 'solver' is that it solves LPs */
>       OsiLPBarrier* bsolver = dynamic_cast<OsiLPBarrier*>(solver);
>       bsolver->OsiLPBarrier::solve()
>       /* no we have selected to solve the LP with barrier */
> Obviously 1) and 2) are sort of equivalent.
> 3) Have a parameter that specifies from which class we want to pick a method
> if it is ambiguous. This solution would effectively hide 1) or 2) from the
> user. On the other hand this does require some coordination among totally
> independent classes (or some serious juggling with typeid information). 
> 
> If these problems wouldn't be enough then we also have to consider
> integerality, so there will be another pillar on the bottom: OsiInteger, which
> contains nothing but integrality info on the data. Then we can have class
> OsiMILP : public OsiLP, public OsiInteger;
> etc. all rising to the top.
> 
> So, I'd like to solicit comments on this (e.g., did I remember correctly :-).
> Once we come to a consensus how it should be done, I'll create a development
> branch for Osi and would be very happy if someone would voluteer to make the
> transition :-). If noone has the time now I'll do it eventually, but I doubt
> I'll have time before sometime in December.

There also was a general proposition that we do try - catch around all
methods in unitTest() for the OsiSolver, OsiSimplexSolver, etc. This would
provide user with an info on what methods are really implemented right
after Osi was compiled with a particular solver.

Best regards,
Mikhail

> 
> Cheers,
> --Laci
> 
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at www-124.ibm.com
> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-discuss
>