<br><font size=2 face="sans-serif">Antonio,</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">John Forrest</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Antonio Frangioni <frangio@di.unipi.it></b>
</font>
<br><font size=1 face="sans-serif">Sent by: coin-discuss-bounces@list.coin-or.org</font>
<p><font size=1 face="sans-serif">12/14/2005 09:16 AM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
Discussions about open source software for Operations Research
</font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">Discussions about open source
software for Operations Research <coin-discuss@list.coin-or.org></font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">[Coin-discuss] Quadratic
costs in OSI: update [+other thing]</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>We *could* be about to try coming up with a proposal
to add handling <br>
of quadratic<br>
costs in the OSISolver interface. However, reviewing the discussion <br>
and the current<br>
status of OSISolver I think I have to ask the question again.<br>
<br>
The question was:<br>
<br>
>> is it OK for everybody that *every* OSISolver is, in general,
a QP <br>
>> solver, except<br>
>> that some may refuse to implement the QP-specific methods throwing
<br>
>> an exception?<br>
>> Or a cleaner but more cumbersome solution where a OSIQPSolver
<br>
>> deriving (??) from<br>
>> OSISolver is required? In the latter case, what should be the
<br>
>> actual inheritance<br>
>> diagram? I'm thinking e.g. to how OsiSimplexInterface enters the
<br>
>> picture (since<br>
>> QP-simplex is also in the cards ...).<br>
<br>
And the authoritative answer I got was:<br>
<br>
> Separation of QP functionality from the current OSI is a Good Thing.<br>
><br>
> It seems like the natural hierarchy is to extend the <br>
> OsiSolverInterface base class<br>
> with OsiQpSolverInterface, which adds base-class versions of calls
<br>
> necessary to support<br>
> QP (not simplex-specific ones though--see later). Then <br>
> OsiXxxQpSolverInterface would be<br>
> derived from OsiXxxSolverInterface and OsiQpSolverInterface. You
<br>
> could derive<br>
> OsiQpSimplexInterface from OsiSimplexInterface and a solver that <br>
> supports QP simplex<br>
> would be derived from that as well.<br>
<br>
Now, this is neat from the OOP viewpoint, and I can swallow the pill. <br>
However, the<br>
latest versions of OSISolver have gone in the exact contrary <br>
direction by killing<br>
OsiSimplexInterface as a separate class and having it "gobbled up"
by <br>
the base class.<br>
Or am I missing something?<br>
<br>
Because the expected number of methods in OsiQpSolverInterface is <br>
quite low, is it<br>
really worth to pay the price of a new class, virtual inheritance and <br>
all the rest?<br>
The advantage of adding methods to the base class is that one <br>
provides them with<br>
"void" (but not pure vitual) implementations and none of the
sub- <br>
projects need to<br>
touch a line of their code unless they can and want implement the new <br>
stuff.<br>
<br>
Opinions?<br>
<br>
Another thing: I stumbled upon the fact that OsiSolverInterface does <br>
not allow the<br>
user to change coefficients (other than costs/RHSs) individually. I <br>
need to change<br>
rows of the system: I could delete them and re-add them changed, but <br>
then I had to<br>
add a dictionary to account for the shuffled row names, which I can <br>
spare otherwise.<br>
Taking into account that:<br>
<br>
- this is just deleting a row/column and adding one, except giving <br>
the new one<br>
the name of the old one;<br>
- every solver I looked to actually has some ChangeCoefficient() <br>
method anyway;<br>
<br>
wouldn't it be reasonable to have this feature added? YAIITWL (Yet <br>
Another Item<br>
In The Whish List ...)<br>
<br>
Regards<br>
<br>
Antonio<br>
<br>
<br>
<br>
Antonio Frangioni - Associate Professor
- Università di Pisa<br>
Dipartimento di Informatica - Largo B. Pontecorvo, 3 - 56127 Pisa, Italy<br>
Ph: +39 050 2212789, Fax: +39 050 2212726, Web: www.di.unipi.it/~frangio<br>
<br>
<br>
_______________________________________________<br>
Coin-discuss mailing list<br>
Coin-discuss@list.coin-or.org<br>
http://list.coin-or.org/mailman/listinfo/coin-discuss<br>
</tt></font>
<br>