[Coin-discuss] setColSolution

Tue Apr 29 20:48:20 EDT 2003

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.

JP Fasano
jpfasano at us.ibm.com
(914)945-1324  (tie line 862-1324)
COIN www.coin-or.org

                      Brady Hunsaker                                                                                                                 
                      <hunsaker at isye.gatech.edu>                   To:       coin-discuss at www-124.southbury.usf.ibm.com                              
                      Sent by:                                     cc:                                                                               
                      coin-discuss-admin at www-124.southbury.        Subject:  [Coin-discuss] setColSolution                                           
                      usf.ibm.com                                                                                                                    

                      04/29/2003 09:34 AM                                                                                                            
                      Please respond to coin-discuss                                                                                                 

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