[Coin-lpsolver] basisIsAvailable()

[Francois Margot]

On Thu, 10 Nov 2005, Matthew Saltzman wrote:

> On Thu, 10 Nov 2005, Francois Margot wrote:
>
>> 
>> 
>> On Thu, 10 Nov 2005, Matthew Saltzman wrote:
>> 
>>> On Wed, 9 Nov 2005, Francois Margot wrote:
>>>> 
>>>> I must add that the Doxygen doc of OsiSolverInterface could be improved 
>>>> (I know, I can do it myself; except that to figure out what is supposed 
>>>> to
>>>> be returned by isProvenOptimal() you have to look at solver 
>>>> implementations
>>>> and they are not consistent with each other ...). The current doc on
>>>> isProvenOptimal() is the terse:
>>>> 
>>>>   Is optimality proven?
>>> 
>>> Of course, what that means is algorithm dependent.
>>> 
>> 
>> Well, this is exactly what I don't like. The purpose of Osi, I thought, is 
>> to have an interface that is solver independent. To obtain that,
>> Osi has to impose return codes that are solver independent, and have
>> enough documentation so that people implementing a solver interface know 
>> exactly what is required.
>
> In the early days of OSI design, much care was taken to avoid using the term 
> "solver independent".  Instead, "solver agnostic" was adopted to imply that, 
> while the API was the same, the interface would "adapt" in certain ways to 
> the behavior of the underlying solver.  That choice made development of SIs 
> simpler, but has proved problematic in just the ways one would have 
> predicted.
>
> I don't think the choice was entirely unjustifiable.  The driving idea was 
> the "principle of least surprise", but the question was, who's surprise is to 
> be minimized?  A CPLEX user migrating to OsiCpxSolverInterface would be least 
> surprised by solver-agnostic behavior, but an OSI user migrating from CPLEX 
> to CLP or vice versa would be least surprised by solver-independent behavior.
>
> One example was that, because we called the underlying solver's MPS reader 
> (simplifying development), you couldn't guarantee that you were solving the 
> same problem when you switched underlying solvers.  You could, however 
> guarantee that the problem read into CPLEX and the problem read into 
> OsiCpxSolverInterface would be the same. The result was John's readMPS(), a 
> retrofit to make sure that we had a consistent way to get the same problem 
> into any solver in the same way.
>
> Another example is the kind of thing we are discussing here.
>
> For the next version, we've largely abandonded solver agnosticism as a design 
> principle.
>

This begs for the following question: When will mere mortal have access to the
new version of Osi?

Francois