[Coin-lpsolver] Re: COIN and CLP concern

[John J Forrest]

Larry,

A possible (sl)eazy solution is to use output option on standalone version 
which corresponds to some parameter on writeMps.  Use clp and enter 
output??

clp ...... -output 6 -export file.mps puts out exact IEEE format encoded 
as gibberish looking characters i.e. 64 bit doubles are encoded as 11 or 
12 ascii characters.

John Forrest



"Larry A. Taylor" <ltaylor at seas.ucla.edu> 
11/19/2007 04:51 PM

To
John J Forrest/Watson/IBM at IBMUS
cc
coin-lpsolver at list.coin-or.org
Subject
Re: COIN and CLP concern






At 10:04 AM 11/19/2007, John J Forrest wrote:
>Larry,
>
>Your problem as defined by the mps file you sent is infeasible.  The
>trouble with infeasible problems is that they can have local optima! i.e.
>if you get just the right basis you may be able to get enough variables 
to
>come in just under the feasibility tolerance.  Also different codes have
>different tolerances.
>
>If I grep for R71 on your file I get -
>
>  E  R71
>     C2144     R71       1.             R72       4691.9899002
>     C2145     R71        -1.           R72        -4691.9899
>     C2146     R71        -1.           R72        -4691.9899
>     C2147     R71        -1.           R72        -4691.9899
>     C2148     R71        -1.           R72        -4691.9899
>     C2149     R71        -1.           R72        -4691.9899
>     C2150     R71        -1.           R72        -4691.9899
>     C2151     R71        -1.           R72        -4691.9899
>
>R72 is also an E row with zero rhs
>
>So as long as any of C2144-C2151 are nonzero then this problem is 
infeasible.

I see a problem that I did not understand, and it brings up another one.

The example you give is only infeasible given a much stricter tolerance 
than
is possible to express on the MPS cards. The file I sent was, indeed, 
produced
by COIN-CLP itself: the 4691.9899002 and the  -4691.9899 is exactly the
same double precision floating point number with opposite sign. That is, I
have a dump of the numbers that were given to COIN, and they have the
same magnitude as double floats as each other.

It appears that it is not possible to express greater precision in the 
twelve
columns of the ancient MPS format. When COIN writes out the problem
in MPS format, the negative number takes a column for the minus sign,
and drops some significant digits that wouldn't fit in the field.

How can I:
(1) Use relative rather than absolute tolerance for feasibility in 
COIN-CLP, etc.
(2) express that some constraints are strict conditions in feasiblity, 
others
  lax;
(3) Force COIN-MP output of MPS files to keep the same number of
significant digits for each output number, so that it will "round-trip"
correctly;
(4) Predict what COIN-CLP will do with my files?

LAT


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/clp/attachments/20071120/c4177e2f/attachment.html>