[Coin-discuss] CGL design

[Matthew Galati]

Hi Lou,

The design I have in mind could work as follows.

First, for each CGL class, remove any dependence on OsiXxxSolver methods. A cut generator is suppose to allow for "separation methods" and should not be bound to a LP solver (or any type of solver, for that matter). A cut generator needs to know:
 1.) a description of the polyhedron,
 2.) the point you are trying to separate.

So, each CGL (generateCuts method) should ask for:
 1.) a CoinPackedMatrix, row bounds, col bounds, integrality, ...,
 2.) some point (double * x).

Better yet, we should have an OsiModel for (1) - which I think was part of the Osi2 design? Separation of solver and model was one of the goals - right?

Then, at each call of the cut generator, all you are doing is passing around pointers to this information. We do this already - it is just hidden inside OsiXxxSolver - which makes it inflexible.

Now, if the cut generator "needs" additional information, you can just enforce it with additional arguments to generateCuts. For example, gomory needs a tableau, or a simplex interface. If the user cannot provide that, they cannot use it.

Other cuts "want" additional info, but don't necessarily "need" it. For example, reduced costs, in some cases, are just used to provide an ordering scheme for lifting. A smart cut generator will use it, if it is provided (non-null) - else, it will use something else to do its ordering.

This would solve the problem of using CGL as an independent library.

Now, to allow for what we are use to now - we would need to add some methods inside OsiSolver which simply wrap the CGL generateCuts methods, getting the input arguments from OsiXxxSolver. Then, using CGL in the context of Osi will be straightforward, as it is now.

Matt


 

> -----Original Message-----
> From: coin-discuss-bounces at list.coin-or.org 
> [mailto:coin-discuss-bounces at list.coin-or.org] On Behalf Of Lou Hafer
> Sent: Monday, March 13, 2006 6:24 PM
> To: coin-discuss at list.coin-or.org
> Subject: Re: [Coin-discuss] CGL design
> 
> Matt,
> 
> 	Is a fake solver (derived class OsiFakeSolverInterface) 
> practical?  Hard to say from this distance, but it might be 
> that by faking the solve routines and a few others, you can 
> give the appearance of having the necessary information at 
> the ready.  The question would be whether you can produce a 
> value --- a reduced cost, say --- from the information you 
> load into the solver, or a priori (e.g., getReducedCost 
> always returns a vector of zeros).
> 
> 	Easy enough to create.  Start with a derived class that 
> leaves everything to OsiSolverInterface, and reimplement 
> virtual methods as they're needed.
> 
> 	Alternative:  Take one of the existing 
> OsiXXXSolverInterface classes for a foreign solver (clp would 
> be a bad choice here, I think), neglect to install the 
> underlying solver, do a link, and write stubs for the 
> undefined routines (which should be the routines supplied by 
> the solver).  Now you have a bunch of interface machinery 
> (mainly, caching of values in the interface).  If one of 
> those stubs is ever executed, well, you know you're in trouble.
> 
> 	From the other direction, if the author of the cut 
> generator really thought that info obtained from the 
> underlying solver was useful and/or necessary, you might be 
> better off to modify the generator so that it doesn't try to 
> make decisions based on bogus values.
> 
> 							Lou
> 
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-discuss
>