[Coin-discuss] CGL design

[Lou Hafer]

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