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

[John J Forrest]

Antonio,

I merged OsiSimplexInterface with the base class because it had originally 
been designed as a way for people to build their own simplex algorithms 
but instead was being used to achieve fairly basic computations such as 
obtaining a row of the tableau.  In my work (and that of others) I found 
it more natural to be able to ask a solver whether it could do certain 
tasks.  So I would agree with your suggested method of extending the base 
class (and being able to ask a solver whether it can handle a quadratic 
objective).  I would think that a quadratic objective was no more 
specialized than integer variables which were of course in from day one 
due to the history of OsiSolverInterface.

When (if :-)) the new design is implemented then quadratic can be 
implemented in a clean abstract way but for now I would vote for extending 
OsiSolverInterface.

As for changing coefficients,  I agree that it would be useful but it 
might be some work for the maintainers of some interfaces.  As a 
compromise we might add a "replaceMatrix" method which would just check 
dimensions of new matrix are same as those of existing model.  This should 
be easy to implement as it should just be a subset of loadProblem.  Then 
the base implementation of "modifyCoefficient" would be - get 
CoinPackedMatrix from model, use CoinPackedmatrix->modifyCoefficient(), 
replaceMatrix.  This could of course be extended to more general methods 
working on CoinPackedMatrix.  Obviously individual solvers could then 
implement more efficient methods.

John Forrest



Antonio Frangioni <frangio at di.unipi.it> 
Sent by: coin-discuss-bounces at list.coin-or.org
12/14/2005 09:16 AM
Please respond to
Discussions about open source software for Operations Research 


To
Discussions about open source software for Operations Research 
<coin-discuss at list.coin-or.org>
cc

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






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


_______________________________________________
Coin-discuss mailing list
Coin-discuss at list.coin-or.org
http://list.coin-or.org/mailman/listinfo/coin-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/coin-discuss/attachments/20051214/62c89e86/attachment.html>