[Cgl] CGL Design - suggested CoinSnapshot

[fmargot at andrew.cmu.edu]

On Fri, 15 Dec 2006 mjs at ces.clemson.edu wrote:

> On Fri, 15 Dec 2006 fmargot at andrew.cmu.edu wrote:
> 
> >
> >
> > On Fri, 15 Dec 2006, John J Forrest wrote:
> >
> >> I will put in rhsSide if you can define it - what do want for ranged rows?
> >
> > As defined in the doc of OsiSolverInterface::getRightHandSide(), it returns 
> > rowUpper for ranged rows.

> That was taken from CPLEX's definition of ranged rows, which seems to be a 
> de facto standard for sense-based representations.

> >
> >> 
> >> 
> >> Matt - I am sure there is a good reason for your anti-Osi slant, but I
> >> can't see what it is.  I can see about not wanting a solver but it seems
> >> odd to duplicate OsiCuts - I can't really see what you are going to do
> >> with cuts other than add them to a solver and as you say it would just be
> >> a copy of the code.
> >
> > I agree that there is no reason to replace OsiCuts by anything else. The 
> > generators need a cut class, the solvers need one and they better use
> > the same class. The location of the cut class can either be on the
> > generators side or the solvers side, and it is on the solvers side in COIN.

> Maybe not the most aesthetically pleasing decision in the long run...
> The cut application method has to be on the solver side, but I don't see 
> (after only a few minutes thought) why the cutlist manager couldn't be on 
> the cut side.  The application method could be (should be) a clean 
> interface.

The cutlist manager could be on the cut side. The problem is that it is now on
the solver side and moving it to the cut side would require lots of changes
in existing code (other than Cgl). It does not mean that it should not 
be done, but I don't think it should be high on the to-do list for now.

> I understand that CGL needs a problem representation that is independent 
> of a solver, but I still sort of lean toward putting it in something like 
> OsiCglSolverInterface.  I think it might be useful for OSI to support such 
> a representation anyway.  One would be able to do everything with it 
> except solve it and extract solutions.

Are there plans for this in Osi in the near future? Are there any such concept
planned in Osi2?

Francois


> 		Matt S.