[Coin-discuss] setColSolution

[Matthew Saltzman]

On Tue, 29 Apr 2003, JP Fasano wrote:

> I would advocate the second option if it can reasonably be implemented.
> If not, then the first option (which is how OsiXprSolverInterface works).
> I don't like the third option because then an application program would
> have to be modifed to use OsiGlpkSolverInterface.
> In my mind this defeats the value of the Open Solver Interface.

I agree with JP's point about the third option.  IIRC (and the XPRESS
implementation was mine), the original spec called for just setting the
cache for solvers that could not accept setting a solution.  The reasoning
was that the solution could be set to anything, and it was not clear (at
least at the time) how to specify a basis to be loaded for a nonbasic
solution.  If solvers could accept a superbasic solution as input, that
would be something to consider, but they can't in general and you are
still stuck trying to specify a basis to associate with the solution.

I'd be open to suggestions for what to communicate to your average solver
about an arbitrary solution, but I don't see an immediately obvious way to
proceed.  Setting just the cache certainly looks to me like the easy way
out.  Because of this issue, I don't think the unit test relies on much
in the way of properties of the solution set by setColSolution() or
setRowPrice() anyway.

Brady wrote:
>
> I've been correcting some of the problems with OsiGlpk, particularly
> those that show up in unitTest.  One problem is that we (Vivian and I)
> never included an implementation of setColSolution or setRowPrice.
>
> The main reason is that GLPK doesn't currently have a way to use these
> values.  GLPK does allow you to specify the basis status of variables
> (basic, nonbasic at upper bound, nonbasic at lower bound), but not the
> values themselves.
>
> I'd appreciate any advice here.
>
> One option is to "set" the values that are cached, but not tell GLPK
> about them at all.  It looks like OsiXpr does that right now.  This
> would be easy to implement and would probably make OsiGlpk pass those
> parts of unitTest.  The main disadvantage that I see is that users may
> be misled, in that their values are not actually being used.
>
> Another option would be to set the cached values, and pass GLPK basis
> information as best as we can.  A value that matches a bound would be
> passed as nonbasic at that bound, for example.  What would we do about
> out-of-bounds values though?  Also, this simple idea might not assign
> a proper basis, since basic variables may also be at bounds.  I'd need
> to check whether GLPK can recover from this.
>
> Another option is to leave it how it is.  This way users know that
> setColSolution and setRowPrice are not usable, but it requires the
> current "glpk workarounds" in the unitTest code.
>
> Any advice?  Thanks,
> 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
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at www-124.ibm.com
> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-discuss
>
>
>
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at www-124.ibm.com
> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-discuss
>

-- 
		Matthew Saltzman

Clemson University Math Sciences
mjs at clemson.edu
http://www.math.clemson.edu/~mjs