[Coin-discuss] CGL design

[Matthew Galati]

Adding the generatCutsNative( ) method sounds fine too me. That would certainly accomplish the goal, which is to allow a user that is not using OSI, to still use some cut generators.

The only negative I can see in that design, is that you still would force the user to build Osi, to build Cgl - which should not really be the case. However, since we use OsiCuts as the cut data struct returned by CGLs, we already have dependence on Osi. Then again, I am not really sure why OsiCuts are in Osi and not in Coin - cuts can be a generic data structure too. But, this goes back to the need for separation of model and solver.

Thanks,
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: Friday, March 17, 2006 5:06 PM
> To: coin-discuss at list.coin-or.org
> Subject: RE: [Coin-discuss] CGL design
> 
> Matt,
> 
> 	A Cgl interface independent of OSI makes some sense.  
> Using an OSI to provide all the parameters for the generator 
> is very efficient when embedded in the COIN context.  And it 
> makes it possible to simply accumulate an array of pointers 
> to cut generators and execute them all with a uniform call.
> 
> 	Using an OSI as the carrier makes less sense if you 
> want to use COIN cut generators but don't want to use a 
> solver through an OSI interface. At one level, it's not too 
> difficult --- the `native' interface for CoinPresolve is one 
> example. But you'll definitely lose the uniform interface, 
> given the large variation in information required for the 
> algorithms now hidden inside CglCutGenerator objects. 
> (Several of these algorithms are definitely not your 
> traditional cut generators.)
> 
> 	I wouldn't go the route of adding wrappers within 
> OsiSolver classes. It burdens an OSI implementor with an 
> ever-growing number of interface functions.
> I don't think anyone will yell too loudly if I say that OSI 
> has already grown to an unwieldy size. Separation of the 
> model and solver aspects should result in two classes that 
> are individually more manageable.
> 
> 	I'd go another way to get a `native' Cgl interface.  
> For each current CglXXX class, keep the current OSI-centric 
> interface.  But the top-level subroutine should do nothing 
> except extract the required data and pass it into the cut 
> generation algorithm.  One approach:
> 
>   CglXXX::generateCuts(OsiSolverInterface,OsiCuts)
>   {   ---
>     << break out parameters >>
> 
>     generateCutsNative(param1, param2, param3, ..., paramN)
>     
>     << repackage parameters >>
>     
>     return ; }
> 
> Alternately, replace the single generateCutsNative() call 
> with a series of calls that load individual portions of the 
> data (loadMatrix(), loadSolution(), etc.) The burden for 
> supplying the interfaces for individual cut generators stays 
> with the implementors of the generators. If the `native' 
> generator calls are public, you have the OSI-independent 
> interface you want, with little additional work.
> It's mostly a matter of organisation --- right now, there's 
> no incentive to break out the parameters implicitly carried 
> by the solver until they're actually needed. In theory, it 
> should be possible to rewrite any GglXXX in this way, as long 
> as it doesn't actually require a solver to do cut generation.
> 
> 								Lou
> 
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-discuss
>