Ticket #4319 (closed defect: fixed)
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@… |
Description
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.
Attachments
Change History
comment:1 Changed 6 years ago by jdsiiro
- Version 1.0 deleted
- Milestone changed from Coopr 3.x to Coopr 3.2
Changed 6 years ago by khunter
- attachment number_formatting.tgz added
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)
Kevin:
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.
John:
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.
Some notes on this: internally, cpxlp.py uses "%+f" to format all coefficients. The simple solution is probably to define a local parameter:
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...