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

[Antonio Frangioni]

>> 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.

A couple of years ago we made the following proposal, which we have  
used in
our codes for years now. The idea is that one typically wants an  
handy enum
for the parameters names, like

    enum IntParam { kIntParam1 , ... kIntParamn ,
		   kLastIntParam
                    };

but then you can legally declare the "set int parameter" function like

   virtual void SetIntPar( const int wp , int value );

and pass the enum as the first parameter. The rationale for this and  
the funny
last value of the enum is that in any derived class you then may do

    enum MoreIntParam { kDerivedIntParam1 = kLastIntParam , ... ,
                        kDerivedIntParamh };

and then in the overloaded version of SetIntPar() catch for the extra  
ones,
throwing the method of the base class if the "wp" int parameter is  
not one
specific of the derived class.

This also allows for easy "translating" of node names between an  
existing
set of parameters and those to be passed to the OSI solver: it's  
enough to,
say, define the OSI parameters as the old ones plus kLastIntParam and  
then
subtract in the call.

At the time the proposal was not deemed acceptable, I guess because  
of focus
on enforcing strict compliance to the rule of the interface (which is  
good).
Maybe now the tide has changed? I, for one, like to be able to deal the
"generic" and "specific" sets of parameters in an uniform way. Plus, the
fact that the derived class gets to see the calls to parameters of  
the base
class and can "react" to them accordingly is sometimes useful---that  
is, if
your base class is not pure virtual, which does not apply to
OsiSolverInterface but it may apply somewhat lower in the hierarchy  
(assuming
there is one).

					Best

					Antonio


Antonio Frangioni    -    Associate Professor    -    Università di Pisa
Dipartimento di Informatica - Largo B. Pontecorvo, 3 - 56127 Pisa, Italy
Ph: +39 050 2212789, Fax: +39 050 2212726, Web: www.di.unipi.it/~frangio