[Coin-osi-devel] Re: [Coin-discuss] set MILP gap

[Michael Hennebry]

On Thu, 25 Oct 2007, Lou Hafer wrote:

> 	It seems to me that more parameters and methods is the wrong way to go.
> >From the developer side, it places a huge burden on the implementor of a new
> OSI.  From the user side, you have no guarantee that the underlying solver
> supports any significant percentage of the many methods already in OSI.  The
> goal of `plug-and-play' solvers is lost.
>
> 	From a software engineering viewpoint, it's bad because the complexity
> and capabilities offered by the interface layer should be a reasonable match to
> the capabilities of the underlying solver class (exterior point, interior point,
> branch-and-cut, etc.). And the complexity of any individual class should be
> limited if the internal and external interactions are to be understood.

IIRC, at one time someone had suggested
using a generic parameter passing mechanism.
It would include methods like
int setFloatParameter(enum ParameterType pt, double value, int *fromSolver);
The solver class would return nonzero if pt wasn't valid for it.
The solver class would return zero if value was passed to the solver.
In that case, *fromSolver would be used to store the solver's return code.

One might want to consider adding another return code for when
the solver returns an error indicator and fromSOlver is null.

Adding a parameter would mean adding another case to a big switch.

There would also be:
int getFloatParameter(enum ParameterType pt, double *toVal, int *fromSolver);


-- 
Mike   hennebry at web.cs.ndsu.NoDak.edu
"Horse guts never lie."  -- Cherek Bear-Shoulders