[Coin-discuss] CGL design

[Lou Hafer]

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