[Coin-discuss] more OSI clarifications

[Brady Hunsaker]

As promised, I have some more questions about OSI.  But first, the
three of us who expressed opinions about the IsProvenXXX and
IsXXXLimitReached functions all seemed to favor some changes not just
to the documentation but also to the interface itself.  

I'd really appreciate it if someone with "access" could let us know
what the procedure is for changes.  I don't mind coding up proposed
changes (even correcting some of the interfaces), but I'd like to know
there's a chance they would ever be used before I take the time.
After the INFORMS conference it sounded as though the
OsiSolverInterface class might be redesigned with a different
inheritance scheme.  If that's going to happen, it might be a natural
time to introduce these changes as well.  I'd just appreciate someone
with inside knowledge letting us know.


Today, my comments concern setColSolution and setRowPrice.  When I
look at the existing interfaces, OsiCpx tries to use these to set a
starting point for optimization, OsiXpr changes its cached values but
does not appear to actually use the information during solving (it
never tells the solver), and OsiOsl tells the solver but I can't tell
from the documentation whether OSL actually uses the values.  I can't
tell whether OsiVol uses the information.

My intuitive understanding of these two functions is that they allow
us to give the solver a starting point for optimization, and the
intent is that the solver will make use of this information, though
the documentation explicitly states that the solver may or may not.
OsiCpx tries to pass it on but has a significant error (I think),
OsiOsl appears to do things correctly, and OsiXpr doesn't even try,
which I think we should correct.

For simplex-based solvers, one difficulty is that starting from an
advanced basis requires information about the basis (like in the warm
start class), rather than just variable values.  I guess any solver
that can accept plain solution values internally converts them to
basis information.  GLPK does not provide a way to do this, so I'm
planning to write this conversion as part of the interface.

The main confusion I see now is what the role of the two functions
is.  The documentation seems to indicate that setColSolution is used
for passing primal solution values for structural (column) variables
only.  Using this information, it is possible to calculate the values
of artificial variables (row slacks) and to find a basis for the
solution (feasible or infeasible) if one exists.

My understanding of setRowPrice is that it is used to pass in dual
solution values corresponding to artificial (row) variables only.
Using this, it's possible to compute dual values corresponding to
structural variables and to find a basis for the solution if one
exists.

The current OsiCpx interface interprets the values from setRowPrice as
primal values for row variables (slacks) rather than dual values.  I
believe this is incorrect.

So here are my questions:
-Is this how other people understand these two functions?
-How should we interpret calls to both setColSolution and setRowPrice
together?  It doesn't really help any solver that I know of to give
both pieces of information, so my suggestion is that the most recent
call is the only one that really counts, though interfaces could try
to avoid redundant computations by checking whether they identify the
same solution using complementary slackness.

Any other suggestions?

Brady

----------------
Brady Hunsaker
Georgia Institute of Technology
Program in Algorithms, Combinatorics, and Optimization
School of Industrial and Systems Engineering

E-mail address:   hunsaker at isye.gatech.edu