[Coin-discuss] OSI design and cooperation with COIN

[Laszlo Ladanyi]

I have to eat my words :-(...

I was working yestarday and all day today trying to finish the implementation
of the design Luigi and Antonio suggested (to get it clean and efficient) but
so far failed. Tomorrow morning I'll post a longer discussion on what the
problems are.

Anyway, for now we'll still do a reorganization of the packages to make the
structure of the repository cleaner. Also, there are lots of changes (mostly
additions) in the devel tree which should become the stable version ASAP.
Therefore we'll just make the current devel tree to be the stable one tomorrow
(and do the reorg) and the OSI redesign will go to the next devel tree. But we
should do the redesign eventually (and the sooner the better). 

Until tomorrow,
--Laci

On Fri, 20 Jul 2001 coin-discuss-admin at dwoss.lotus.com wrote:

> Hi,
> 
> Sorry that it so long to respond... 
> 
> The class design suggested sounds good. We were thinking a bit on whether the
> solver interface should be even more general (i.e., not to assume even linear
> constraints), but then one could write a brand new class hierarchy instead. We
> got to assume something :-).
> 
> We may shorten the name SolverInterface to SI. It's just too long to type :-).
> 
> Actually, we have been coding the conversion for the past couple of days (it's
> not that hard, just there are other things to do, too), and expect to make the
> switch at the same time as the current devel version becomes the stable
> version. The planned date for that is next Monday. So if all goes well, You
> can start to look at it on Tuesday. I'll post to the list about our progress
> with the switch.
> 
> --Laci
> 
> On Sun, 15 Jul 2001, Luigi Poderico wrote:
> 
> > Hi to J.P., Laci and everyone,
> > 
> > I have talked a lot with Antonio about different designs of OSI and the
> > possibility to cooperate with COIN community, reaching the following
> > statements:
> > 
> > *** OSI Design ***
> > The hierarchy of the OSI classes should be the following:
> > 
> > OsiSolverInterface
> >     OsiLpSolverInterface : public virtual OsiSolverInterface;
> >         OsiSimplexLpSolverInterface : public virtual OsiLpSolverInterface;
> >         OsiVolumeLpSolverInterface : public virtual OsiLpSolverInterface;
> >         OsiBarrierLpSolverInterface : public virtual OsiLpSolverInterface;
> >     OsiQpSolverInterface : public virtual OsiSolverInterface;
> >     OsiMipSolverInterface : public virtual OsiSolverInterface;
> > 
> > The class OsiSolverInterface should be contain all and only the methods
> > shared by all the others interfaces: basically methods for express linear
> > constraints.
> > The other classes add to OsiSolverInterface methods for linear programming,
> > quadratic programming, etc.
> > All the classes of the diagram are abstract having some virtual pure
> > methods, i.e. Solve() method.
> > 
> > Concrete classes close the diagram, eventually making some diamonds: i.e.
> > OsiOslSolverInterface close a big diamond deriving from
> > OsiSimplexLpSolverInterface, OsiBarrierLpSolverInterface,
> > OsiQpSolverInterface and OsiMipSolverInterface; OsiVolSolverInterface derive
> > from OsiVolumeLpSolverInterface; etc.
> > 
> > *** Cooperation with COIN community ***
> > The smallest step, in order to transform the actual OSI classes diagram (say
> > OSI version 1) in to the diagram above suggested (say OSI version 2), could
> > be to write the core of diagram paying attention to minimize the code
> > rewriting.
> > 
> > The core of diagram could be the following:
> > 
> > OsiSolverInterface
> >     OsiLpSolverInterface : public virtual OsiSolverInterface;
> >         OsiOslSolverInterface: public OsiLpSolverInterface;
> >         OsiCpxSolverInterface: public OsiLpSolverInterface;
> >         OsiVolSolverInterface: public OsiLpSolverInterface;
> >         OsiXprSolverInterface: public OsiLpSolverInterface;
> >     OsiQpSolverInterface : public virtual OsiSolverInterface;
> >         OsiCpxSolverInterface: public OsiQpSolverInterface;
> > 
> > Granting that the public interface offered by OsiSolverInterface (version 2)
> > + OsiLpSolverInterface cover completely the public interface of
> > OsiSolverInterface (version 1), OsiVolSolverInterface and
> > OsiXprSolverInterface doesn't require any modification.
> > Only OsiOslSolverInterface and OsiCpxSolverInterface need some extensions in
> > order to (eventually) implement the QP facility of OsiQpSolverInterface.
> > 
> > Actually, we have checked that no methods are required in
> > OsiLpSolverInterface because the interface of OsiSolverInterface is enough,
> > but we think that when
> > OsiSimplexLpSolverInterface, OsiVolumeLpSolverInterface and
> > OsiBarrierLpSolverInterface will be implemented OsiLpSolverInterface will
> > contain some  shared methods , i.e. bool ReturnigBaseSolution(). This is the
> > reason why we left an empty class in the core diagram.
> > 
> > If you accomplish our ideas, we can wait the next release of OSI and
> > starting from it to write the core diagram, including OsiLpSolverInterface
> > and OsiQpSolverInterface, and extend OsiCpxSolverInterface (version 1).
> > 
> > Bye bye,
> > Luigi
> > 
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > Poderico Luigi
> > Ind.: via Pesenti, 19 - 56124 Pisa
> > Tel.: +39 329 8151210
> > Fax. +39 1782261666
> > e-mail: lupoderi at tiscalinet.it
> > 
> > _______________________________________________
> > Coin-discuss mailing list
> > Coin-discuss at oss.software.ibm.com
> > http://oss.software.ibm.com/developerworks/opensource/mailman/listinfo/coin-discuss
> > 
> 
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at oss.software.ibm.com
> http://oss.software.ibm.com/developerworks/opensource/mailman/listinfo/coin-discuss
>