<br><font size=2 face="sans-serif">Larry,</font>
<br>
<br><font size=2 face="sans-serif">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??</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">John Forrest</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Larry A. Taylor"
<ltaylor@seas.ucla.edu></b> </font>
<p><font size=1 face="sans-serif">11/19/2007 04:51 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">John J Forrest/Watson/IBM@IBMUS</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">coin-lpsolver@list.coin-or.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: COIN and CLP concern</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>At 10:04 AM 11/19/2007, John J Forrest wrote:<br>
>Larry,<br>
><br>
>Your problem as defined by the mps file you sent is infeasible. The<br>
>trouble with infeasible problems is that they can have local optima!
i.e.<br>
>if you get just the right basis you may be able to get enough variables
to<br>
>come in just under the feasibility tolerance. Also different
codes have<br>
>different tolerances.<br>
><br>
>If I grep for R71 on your file I get -<br>
><br>
> E R71<br>
> C2144 R71 1.
R72 4691.9899002<br>
> C2145 R71 -1.
R72 -4691.9899<br>
> C2146 R71 -1.
R72 -4691.9899<br>
> C2147 R71 -1.
R72 -4691.9899<br>
> C2148 R71 -1.
R72 -4691.9899<br>
> C2149 R71 -1.
R72 -4691.9899<br>
> C2150 R71 -1.
R72 -4691.9899<br>
> C2151 R71 -1.
R72 -4691.9899<br>
><br>
>R72 is also an E row with zero rhs<br>
><br>
>So as long as any of C2144-C2151 are nonzero then this problem is infeasible.<br>
<br>
I see a problem that I did not understand, and it brings up another one.<br>
<br>
The example you give is only infeasible given a much stricter tolerance
than<br>
is possible to express on the MPS cards. The file I sent was, indeed, produced<br>
by COIN-CLP itself: the 4691.9899002 and the -4691.9899 is exactly
the<br>
same double precision floating point number with opposite sign. That is,
I<br>
have a dump of the numbers that were given to COIN, and they have the<br>
same magnitude as double floats as each other.<br>
<br>
It appears that it is not possible to express greater precision in the
twelve<br>
columns of the ancient MPS format. When COIN writes out the problem<br>
in MPS format, the negative number takes a column for the minus sign,<br>
and drops some significant digits that wouldn't fit in the field.<br>
<br>
How can I:<br>
(1) Use relative rather than absolute tolerance for feasibility in <br>
COIN-CLP, etc.<br>
(2) express that some constraints are strict conditions in feasiblity,
others<br>
lax;<br>
(3) Force COIN-MP output of MPS files to keep the same number of<br>
significant digits for each output number, so that it will "round-trip"<br>
correctly;<br>
(4) Predict what COIN-CLP will do with my files?<br>
<br>
LAT<br>
<br>
</font></tt>
<br>