[Osi] [Clp] set row solution (activities)

[Lou Hafer]

Folks,

> If the solution is the solver's, then it's generally easy to get the row
> activities (b - s, where s is the row slacks returned by the
> solver--AFAIK, all solvers offer that information directly).
>
> [ ... ]
>
> In the case of a solution imposed by the user, the mechanism is solver
> dependent.  For solvers that have the ability to compute Ax for
> arbitrary x and unpreprocessed A, that's the thing to do.  For solvers
> that don't, about the only thing to do would be to copy out the current
> unpreprocessed A and do the multiplication in OSI.

     That pretty much sums it up.  Exactly how to accomplish the required
     calculation will depend on the solver and the implementation of the
     OsiXXX.  Since the client code is working in reference to the original
     constraint system, there has to be a copy of that available somewhere,
     or the ability to massage the imposed solution to match the
     preprocessed system.

> What are conditions for a solution to be "valid"?  I don't think it's a
> synonym for "feasible".
>
>							Matt


     Interesting question, to be sure.  If there's an expectation that the
     solution is optimal, then pretty much any change renders it invalid
     until the solver is called to reoptimise.  Feasible is a bit more
     predictable, but still problematic.  Often the client will have a good
     idea of the effect of changes on the optimality or feasibility of the
     current solution. Some way to communicate that to the OsiXXX could be
     useful.

     It's impossible to know the client's mind, so it's impossible to make
     any assumptions about an imposed solution without testing ---
     something I'd argue an OsiXXX should not do automatically.
     Feasibility could be checked without too much work, but optimality
     would be nontrivial in general.
     
     One possibility is a simple boolean that records whether the
     constraint system has been modified since the last time a solution was
     obtained (either from the solver or the user).  The user can then draw
     his/her own conclusion as to whether that's important or not.  We
     could extend that a bit with a hook that says something like
     `modifications coming, do / do not invalidate the current solution.'
     That can be refined to distinguish primal solution and dual solution.

     							Lou