Re: [Help-glpk] proposal for gnu lp/mip low-level format

[Brady Hunsaker]

This is certainly better than MPS format and is consistent with some
other common low-level formats.  The ability to give row and column
names is good.

The one thing I would add is some guidelines about precision and
numerical formats.  Is arbitrary precision allowed in the numbers?  I
guess the idea would be that numbers would be rounded (as always) to fit
in whatever floating-point data type that a solver uses, but with no
predefined precision limit in the file.  Therefore it is possible that
different solvers would round input differently if they use different
floating-point data types.

Also, I would perhaps make it explicit that various notations are
allowed:
-230.7
1.555e-07

What about slightly odd notations?
2.3e0004   (lots of unnecessary digits in the exponent)
231.3e7    (abnormal use of exponent)

Are real number input formats standardized anywhere?  I have a sense of
what's "normal" and what isn't, but I don't know if it's written down
anywhere.  This is important because we don't want some parsers to fail
on certain input files just because they disagreed on whether a format
was acceptable.

Brady


On Wed, 2004-07-21 at 21:30, Andrew Makhorin wrote:
> I propose a (GNU) low-level format for coding lp/mip instances. Below
> here is its brief description. I would appreciate any suggestions.
> 
> Andrew Makhorin
> 
> 
> It is a text format. The file may contain the following lines:
> 
> * comment
> 
> N problem-name
> 
> P problem-class objective-sense num-rows num-cols num-nz
> 
> R row-num F
> R row-num L lower-bound
> R row-num U upper-bound
> R row-num D lower-bound upper-bound
> R row-num S fixed-value
> 
> C col-num F
> C col-num L lower-bound
> C col-num U upper-bound
> C col-num D lower-bound upper-bound
> C col-num S fixed-value
> 
> F col-num objective_coef
> F 0 constant-term
> 
> A row-num col-num constraint-coefficient
> 
> I row-num row-name
> 
> J col-num col-name
> 
> E O F
> 
> All lines, except P-line and E-line, are optional and may follow in
> arbitrary order.
>