[Coin-discuss] Questions about OSI - 6

[Laszlo Ladanyi]

Hello,

On Fri, 6 Jul 2001, Antonio Frangioni wrote:

> 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.).

That's a good idea. Every class in the hierarchy could get its own 1000
possible values. But I still maintain that for setting parameters that are not
in the enum list of any base class one should use direct calls to the actual
solver. That way the solver specific nature sticks out much better in the
application code. 

> 
> 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 ...).

Probably that's true. 

> 
> 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 will make the current devel branch to be the stable branch either this week
or the next week. This branch is still very much LP oriented. Afterwards we
can immediately start a new devel branch that would be based on the new
hierarchy. Splitting up the current class into the LP solver and MIP solver is
rather trivial. The only thing we got to be careful is to maintain the
unitTest code (which is out of date as it is :-( ). That code is supposed to
test the various methods in the classes and when a bug is found a test for
that bug should be added to unitTest.

The other problem is that at the moment we don't really have the manpower to
work on Osi... We can do code review and contribute a bit, but not too much. 
However, since you seem to want to make rather large contributions to COIN
(and your ideas are well thought out), there is no reason why you couldn't
become core developers and have write access to the CVS tree. 

> 
> 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

Best Regards,
--Laci