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

[Brady Hunsaker]

Kendall,

It looks like you're already aware that you can access the GLPK
interface directly by casting the pointer and calling getModelPtr.  Then
you can do anything you like.

I also agree that we should do some more careful thinking about which
parameters we expect solvers to have and add all of those to the common
parameter set.  In fact, there are some other issues about clarifying
standard behavior for OSI interfaces that I think should be addressed at
some point.

I'm not sure whether it makes sense to have the general parameter method
that you're mentioning.  The reason is that it "hides" the fact that
code using those parameters is solver-specific.  The point of OSI is to
have most of your code apply to any solver.  When you do a cast to a
specific solver interface, then it's very obvious that the code is
solver-specific.  It's slightly more annoying, but it seems to me that
it makes the code more readable for later modification.

In the specific case of the two integer optimization routines, I haven't
yet looked at updating OsiGlpk for GLPK 4.9.  It may make sense to
change the branchAndBound call so that the new routine is the default.
I know this doesn't address the question of allowing users their choice
of routines, however.

Brady

Kendall Bailey wrote:
> 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
>>
>>
> 
> 
> _______________________________________________
> Coin-osi-devel mailing list
> Coin-osi-devel at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-osi-devel


-- 
Brady Hunsaker
Assistant Professor
Industrial Engineering
University of Pittsburgh
http://www.engr.pitt.edu/hunsaker/