[Coin-discuss] Quadratic costs in OSI: update [+other thing]

[Antonio Frangioni]

We *could* be about to try coming up with a proposal to add handling  
of quadratic
costs in the OSISolver interface. However, reviewing the discussion  
and the current
status of OSISolver I think I have to ask the question again.

The question was:

>> is it OK for everybody that *every* OSISolver is, in general, a QP  
>> solver, except
>> that some may refuse to implement the QP-specific methods throwing  
>> an exception?
>> Or a cleaner but more cumbersome solution where a OSIQPSolver  
>> deriving (??) from
>> OSISolver is required? In the latter case, what should be the  
>> actual inheritance
>> diagram? I'm thinking e.g. to how OsiSimplexInterface enters the  
>> picture (since
>> QP-simplex is also in the cards ...).

And the authoritative answer I got was:

> Separation of QP functionality from the current OSI is a Good Thing.
>
> It seems like the natural hierarchy is to extend the  
> OsiSolverInterface base class
> with OsiQpSolverInterface, which adds base-class versions of calls  
> necessary to support
> QP (not simplex-specific ones though--see later).  Then  
> OsiXxxQpSolverInterface would be
> derived from OsiXxxSolverInterface and OsiQpSolverInterface.  You  
> could derive
> OsiQpSimplexInterface from OsiSimplexInterface and a solver that  
> supports QP simplex
> would be derived from that as well.

Now, this is neat from the OOP viewpoint, and I can swallow the pill.  
However, the
latest versions of OSISolver have gone in the exact contrary  
direction by killing
OsiSimplexInterface as a separate class and having it "gobbled up" by  
the base class.
Or am I missing something?

Because the expected number of methods in OsiQpSolverInterface is  
quite low, is it
really worth to pay the price of a new class, virtual inheritance and  
all the rest?
The advantage of adding methods to the base class is that one  
provides them with
"void" (but not pure vitual) implementations and none of the sub- 
projects need to
touch a line of their code unless they can and want implement the new  
stuff.

Opinions?

Another thing: I stumbled upon the fact that OsiSolverInterface does  
not allow the
user to change coefficients (other than costs/RHSs) individually. I  
need to change
rows of the system: I could delete them and re-add them changed, but  
then I had to
add a dictionary to account for the shuffled row names, which I can  
spare otherwise.
Taking into account that:

- this is just deleting a row/column and adding one, except giving  
the new one
   the name of the old one;
- every solver I looked to actually has some ChangeCoefficient()  
method anyway;

wouldn't it be reasonable to have this feature added? YAIITWL (Yet  
Another Item
In The Whish List ...)

					Regards

					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