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

[Lou Hafer]

Kendall,

> 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?
>  [ ...  ]
> 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().

	Why not?  No particular good reason that I know of, other than the
rationale I've already mentioned --- trying to present a uniform interface.
Some reasons that might have been applicable five years ago (related to C++ STL
portability across platforms) are probably no longer relevant.

	One of the original OSI designers might have a better answer.

	I'd say ``Go for it.'' Seems like you could probably set it up as a set
of maps in the OsiSolverInterface base class.  The extra parameter should
distinguish the new set of functions, so it likely won't break existing OSIs.
It'd be interesting to see an implementation.

	The biggest hazard, really, is an explosion of special purpose
parameters, which might or might not be picked up by implementers of individual
OSIs.  The net effect might be to reduce interoperability, rather than enhance
it.  The only way to see how that plays out would be to try it.

							Lou