[Coin-osi-devel] More flexible parameter scheme for Osi?

[Laszlo Ladanyi]

Ho about the following solution: There are two kind of parameters, one that's
understood more or less the same way in every solver (like the current
parameters), and another where the param is identified by a pair of strings:  
<solvername, parameter_id>. You pass this pair along with a value to the
OsiSolverInterface and it gets interpreted by OsiXXX. If XXX is the same as
solvername then it checks whether parameter_id is legal for XXX and if so sets
it. The return value of the method can indicate whether the call succeeded,
and if not, where did it fail (wrong solver, unknown id, out of feasible range
for the id, etc.) This way one can aim for solver-agnosticness by trying to
use generic parameters, but if necessary, any parameter is accessible.

Thoughts? Volunteers to implement :-)?

--Laci

On Tue, 26 Jun 2007, Lou Hafer wrote:

> Kendall,
> 
> 	I haven't been much persuaded by the notion that a tagged parameter
> capability of the type you suggest is better than downcasting to the specific
> solver type.  Seems to me that no matter how you phrase it, a priori knowledge
> that the capability exists has to proceed any attempt to use it.  Downcasting
> keeps this front and center in the application code.
> 
> 	But the python situation makes a better case --- it'd be nice to have
> something that works in an environment where the capability to downcast simply
> does not exist.
> 
> 	I do worry about the namespace, though.  There's nothing to prevent
> OsiXXX from implementing parameter `whizbang' in a manner that's completely
> incompatible with OsiYYY's `whizbang'.  When your solver-agnostic code asks
> generic Osi to set `whizbang' to 42, you have no idea what you're getting.  I
> suppose you could have a convention that adds a prefix, `xxx_whizbang',
> `yyy_whizbang'.  You could ask the solver for the correct prefix before starting
> the sequence of calls to tweak parameters.  But you'd still have to remember
> that xxx_whizbang should be 24 to get the same behaviour as yyy_whizbang set to
> 42. Your script is solver-aware, but the downcast issue is avoided.
> 
> 	I'm moving this over into coin-osi-devel and re-titling, where it'll
> stand a better chance of catching other OSI developers. I'm still leaning away
> from this, but more debate will be a good thing.
> 
> 							Lou
> 
> --------------------------------------------------
> In the coin-discuss thread `How to choose a MIP solver in GLPK OSI?', Kendall 
> Bailey writes:
> 
> I initiated the thread referred to in 2006.
> 
> [ http://list.coin-or.org/pipermail/coin-osi-devel/2006-March/000002.html
>   too-short summary: setIntParam(osiOtherParam, "whizbang", 42)
>   -- lh -- ]
> 
> I still believe that the Osi interface should allow client code to push
> arbitrary parameters into a solver and test for success of failure.  The point
> that I made before is that the setXXXparams methods already can return a
> failure, so well written code must already deal with the possibility that a
> particular solver rejects a parameter.
> 
> Say I have a Python extension module which can dynamically load any Osi solver
> library.  Then someone releases a new OsiSuperMIP library with new parameter
> that the base Osi interface knows nothing about.  I will be able to plug the
> OsiSuperMIP solver into Python without modifying the extension module and
> recompiling.  But none of my scripts can take advantage of the new parameters.
> I can't downcast inside a Python script.  The Python extension module (written
> in C++) knows nothing of the methods unique to OsiSuperMIP.
> 
> But if there were a way to pass any tagged int, double or string into the Osi
> interface, then the Python extension module would expose that, and throw a
> runtime exception if the concrete solver being used rejects any given parameter.
> Now I can tweak my scripts to set all the OsiSuperMIP parameters I like and
> never need to break out a C++ compiler.
> 
> Someone suggested I implement a map<> of parameters in the OsiSolverInterface.
> That's not needed.  The default implementation of setOtherXXXParam() is to just
> fail.  Individual Osi solver wrappers would override and accept whatever params
> they can implement.  It would be nice to have a common namespace for parameters
> that are accepted by more than one solver, but not critical.
> 
> My effort was to plug any Osi solver into AMPL.  The AMPL program can pass
> arbitrary parameters to the solver via environment variables.  It makes sense to
> me to just try to pass those right on through.  But without a generic API, the
> AMPL driver needs apriori knowledge of each solver's possible options so it can
> downcast when needed and push the parameters in a solver custom way.
> 
> _______________________________________________
> Coin-osi-devel mailing list
> Coin-osi-devel at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-osi-devel
>