[Coin-discuss] Quadratic costs in OSI?

[Antonio Frangioni]

Hello again.

> The lack of QP support in the OSI not a technical issue, it's only 
> because nobody has done it yet.

That was my understending, that's why the question in the first place 
...

> (1) In the very short term, I'll point out that CLP has a quadratic 
> interface already built (see Clp/ClpQuadraticObjective.cpp and 
> Clp/include/ClpQuadraticObjective.hpp).  This interface could be used 
> directly to get CLP to solve your QPs.  The CLP direct API is fairly 
> OSI-like, so moving back to the OSI itself once QP is implemented 
> shouldn't be very difficult.

Right, but I strongly support the idea of the abstract interface and I 
prefere working
with them if at all possible. That's why the idea of using OSISolver 
whenever possible
and solver-specific hacks in the few points where it is necessary.

> (2) The CLP QP interface probably provides most of the calls that 
> would need to be elevated into OSI to support calls to QP solvers.  It 
> wouldn't be that hard to write an OSI base layer to make the 
> appropriate calls.
>
> (3) The real work is writing calls in the OsiXxxSolverInterface layer 
> for all the solvers.  The best strategy here is probably just to take 
> the solver you want to use and write the suporting calls for it.  
> Solver interface subproject managers or volunteers who want QP support 
> for some other solver would have to fill in the holes once the base 
> class is done.
>
> If you want to take a crack at it, we'd love that.  I'm happy to 
> provide support and I'm pretty sure the other OsiXxx maintainers would 
> as well. In my opinion, your time would be better spent implementing a 
> true QP OSI than trying to hack a solver-specific add-on. If you want 
> us to do it, it may take a bit more time.

I'll see if I can have a programmer taking care of this. At most I'll 
be able to provide
Xxx \in \{ `Clp' , `Cpx' \}. However, the delicate thing will be 
deciding the exact shape
of the interface. When I'll be able to start (which won't be tomorrow) 
I'll post one
proposal for upgrading the OSISolver interface. What may be nice to 
know beforehand is
whether a solution which simply adds the methods to the general 
interface is considered
good by the community, or one should plan an extension of the 
hyerarchy. In other words:
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 ...).

More in general, I think this raises the question as to whether 
OSISolver will ever become
an interface for (nonlinearly constrained?) nonlinear problems solvers, 
and in this case
if the current shape of the interface is suitable for the task. But 
with this I'm surely
slipping into the realm of far away dreams and I definitely stop here.

											Regards

											Antonio