[Coin-osi-devel] More params, glpk 4.9, mip gap

Kendall Bailey krbailey at gmail.com
Wed Mar 15 17:03:44 EST 2006


OSI recognizes a need for int, double and string parameters.  But it
limits the list of params to a small number of common ones, and even
then a solver is free to indicate at runtime that a parameter failed
to be accepted.  Why not add an additional key for each of the three
param types (int, double, string) that allows one to pass in
additional tagged values?

setIntParam( OsiOtherIntParam, "foo", 123 );

would set a "foo" param on the solver with a value of 123.  Something
similar for "hints" could be useful too, although it's a special case
of an integer parameter.

This would cover most cases, reducing the need to downcast<> in order
to access solver specific features.  Driver code would choose whether
to ignore failed param settings or not, as it must do now when using
setXXXParam().

Kendall


On 3/15/06, Lou Hafer <lou at cs.sfu.ca> wrote:
> Kendall,
>
>         At one level, there is no general solution, because you're talking about
> features specfic to a particular underlying solver.  That said, you might have a
> look at the setApplicationData method.  It allows you to pass in a pointer to an
> arbitrary data structure, which you could pass along to glpk.
>
>         This doesn't necessarily help for something like your need to call one
> of lpx_integer or lpx_intopt from OsiGlpk. A solution adopted by other solvers
> is to provide an extension function, specific to the solver, which handles
> solver-specific parameters (OsiClp::setSpecialOptions,
> OsiDylp::dylp_controlfile). The approach is, by definition, solver-specific.
>
>         It's really an open question as to what the appropriate set of
> parameters should be.  Solver capabilities vary widely.  Retaining the
> `plug-and-play' aspect of the OSI interface binds a bit on issues such as this.
>
>                                                         Lou
>
>




More information about the Osi mailing list