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

[Lou Hafer]

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.