[Coin-discuss] Principles for maintaing solutions in a solver interface.

[Lou Hafer]

Folks,

	I've been trying to work out some underlying principles for the
behaviour of a solver interface (SI) with respect to the pre-solver solution,
and I'm left with some puzzles. Here's a sampling.


  * unitTest clearly expects a SI to generate an initial solution when it reads
    a problem from an MPS file --- it tests for this directly. It's easy enough
    to extend this to loadProblem. Both are batch activities.
    
    But what about when the client is incrementally building a system using
    addCol/addRow? Should the SI incrementally maintain a valid pre-solver
    solution? It's possible, but some work would be required to do it
    efficiently.

  * Does a SI possess exactly one solution, or is there a notion of `the
    solution provided by the client' vs. `the solution provided by the
    solver'? If there are conceptually two solutions, which takes precedence?
    The chronologically most recent?
 
  * If I have a solution from the solver, and the client incrementally
    modifies the problem, what are the rules? Should the solver attempt to
    incrementally maintain a solution? Or is it invalid until the next time a
    complete solution is provided (either by the client or the solver)?

  * If the SI has a valid solution (from client or solver), and a call to the
    solver fails, is the existing solution invalidated?

	If I were to make a proposal, for maintenance of solutions in general,
it would be something like this:

  * The SI possesses a single, unique solution.
  
  * The SI will implement a method, inventSolution, that generates a
    `reasonable' initial solution appropriate for the solver. Definition of
    reasonable to be determined.

  * When a problem is loaded, either in batch or incrementally, no solution
    exists until the client calls inventSolution or initialSolve.

  * Modifications to the problem invalidate the existing solution until the
    next call to inventSolution, initialSolve, or resolve.

  * A failed call to the solver invalidates any existing solution.

  * Solutions may be imposed on the SI by the client (setColSolution,
    setRowSolution) but the SI is under no obligation to attempt to impose
    them on the solver.

Admittedly, there's a bias here toward ease of SI implementation.

Matt, you mentioned `the original spec'. Is it still relevant? Is there a copy
around somewhere?

							Lou