[Coin-discuss] Questions about OSI - 5

[Laszlo Ladanyi]

Hello.

>That's true, and actually that's intentional. This way if a user wants to
>access a parameter that's specific to one solver then it's much better if the
>user has to get a pointer to the model and call directly the solver's
>parameter setting routine

I disagree with this, but of course that's only my opinion. Especially if
you are going to go towards the multiple inheritance setting, I think
you should allow the derived classes to extend the range of key values.

Otherwise, you'll have to define in OsiSolverInterface one enum with
all possible parameters for all possible derived classes. So you should
have values for QP classes, various LP classes, MIP classes etc. all
in the base class. The alternative is to have new set/get methods at each
level of the inheritance tree (setSimplexLPIntParam() ...).

I agree with your observation that the managing of the key spaces is
more difficult under multiple inheritance, but it can be managed in
some way (0..1000 base class, 1001..2000 LPs, 2001..3001 QPs etc.).

Anyway it's your choice, of course.

>The solution we'd prefer is Model B, that is to have the dreaded diamond
>multiple inheritance :-). I believe on the long run it ensures a much cleaner
>implementation than hoarding every method into one single class.

I also agree that this looks the most promising solution.

>For now I'd suggest the following hierarchy:
>OsiSolverInterface;
>OsiLpSolverInterface : public virtual OsiSolverInterface;
>OsiSimplexLpSolverInterface : public virtual OsiLpSolverInterface;
>OsiVolumeLpSolverInterface : public virtual OsiLpSolverInterface;
>OsiBarrierLpSolverInterface : public virtual OsiLpSolverInterface;
>OsiQpSolverInterface : public virtual OsiSolverInterface;

Looks very good.

>I'm not sure where to put MIP, derive it from LP or derive it directly from
>the SolverInterface.

I guess MIP should derive directly from SolverInterface. You could have
MIPs that are not based onto LP at all (dynamic programming, CLP ...).

Maybe you could consider

OsiMIPSolverInterface : public virtual OsiSolverInterface;
OsiMIPLPSolverInterface : public virtual OsiMIPSolverInterface;

but I'm not sure it's worth. A MIP-LP solver would have both the
LpSolver and MIPSolver interface (that's the nice thing about
the dreaded diamond).

>Also, we got to decide what is in the solverinterface. Do
>we assume anything? Like linear constraints?

This is a very critical question for which I don't have answers ready.
Of course it's tempting to try to construct an all-around interface
for any possible kind of solver, but this would require much thinking.

Perhaps one should start by modifying as little as possible the
current setting, and then go after further generalizations later
(Rome was not built in one day ...).

>Your comments (however lengthy :-) are very much appreciated.

I'm very happy if you consider this little discussion useful. However,
I also need your opinion. We have to decide if using OSI for one of
our project (which of course could use a QP-OSI, whence the initial
questions). I'd be very happy if we could, but we should start
implementing the things pretty soon. So, the question is: which
version of the OSI interface should we use?

The current version does not support QP. With the new structure of
the classes we have been discussing it would be easy for us, but
that's not what is available now.

Do you see the transiction to the new interface happening anytime soon?
Could we help with that? Once the new interface is ready, how long do
you think it'll take before the various concrete implementations be
ported to the new setting? Who is going to do that? Is there anything
that we can do about that?

We have to plan our efforts for the next three months or so, and we
could definitely use some input about the above issues.

				Best Regards

				  Antonio