Ticket #4319 (closed defect: fixed)

Opened 6 years ago

Last modified 4 years ago

Pyomo .lp writer uses six decimal digits

Reported by: ledelato@… Owned by: unassigned
Priority: normal Milestone: Coopr 3.4
Component: pyomo.core Version:
Keywords: lp-format Cc: kmhunte2@…


I'm copying this directly from the Coopr google group:

Using CPLEX concert, I'd previously written the extensive form of a
stochastic programming model. I've rewritten it with Pysp to use
progressive hedging. When I use Pysp to write the extensive form, the
optimal solution doesn't match the solution found by concert, and the
optimal solution found by concert is infeasible when I plug it into
the model generated by Pysp.

I narrowed the problem down to an equality constraint where several
fractional values must equal one. The LP generated by CPLEX export
model was using 16 decimal places, and Pysp's LP file had 6. When I
manually copied the values from the CPLEX LP file into the Pysp LP
file, the solutions matched.


number_formatting.tgz Download (1.6 KB) - added by khunter 6 years ago.
A few print formats exampled, including %g and %s

Change History

comment:1 Changed 6 years ago by jdsiiro

  • Version 1.0 deleted
  • Milestone changed from Coopr 3.x to Coopr 3.2

Some notes on this: internally, cpxlp.py uses "%+f" to format all coefficients. The simple solution is probably to define a local parameter:

format = "%%+%if" % numfig

Where numfig is the desired precision. The real question is how to propagate the numfig parameter into the LP writer, although as a 98% solution, we could just hard-code it to 16. That change would require updating ALL lp baselines...

Changed 6 years ago by khunter

A few print formats exampled, including %g and %s

comment:2 Changed 6 years ago by khunter

(Copying from a couple recent forum posts, for continuity)

Though it doesn't address the underlying issue that John raises (excessively sensitive models), I believe this could be addressed with a 3 or 4 line change in io/cpxlp.py. The option that we've known about since at least Summer, 2010 (but didn't implement for a reason I now forget) is to replace the %f or %+f format with %s. Another is %g.
Please take a quick look at the attached example code.

Short answer: %s (at 12 significant figures) does not solve the problem. Moving from %f to %g is a no-brainer and actually solves several issues for poorly scaled problems.

comment:3 Changed 6 years ago by khunter

  • Cc kmhunte2@… added

comment:4 Changed 5 years ago by jwatson

  • Milestone changed from Coopr 3.2 to Coopr 3.x

comment:5 Changed 4 years ago by gabeh

  • Status changed from new to closed
  • Resolution set to fixed

Fixed in r7511. Changed from %f (mixed with a few %s's) to using %.17g. See comments in commit for explanation. Thanks to khunter for the helpful attachment.

comment:6 Changed 4 years ago by wehart

  • Milestone changed from Coopr 3.x to Coopr 3.4
Note: See TracTickets for help on using tickets.