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

[Michael Hennebry]

On Thu, 22 Jul 2004, 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.

Is the format supposed to be readily readable or writeable by humans?
If so, I have suggestions.

Allow row and col names where the corresponding numbers are allowed.
A name not given a specific number would get its number from the reader.

In an A line, allow a quote mark to represent the corresponding value
from the previous A-line.
A row of 1's could look something like this:
A  rowq  col1  1
A   "    col2  "
A   "    colc  "
A   "    cold  "

Some problem structures would show up better this way.
Since you specified that this is to be a low level format,
the following suggestion is made with trepidation.

A row [row...] : col [col...] value

would give many matrix elements the same value.
Allowing a 'line' to include multiple lines
would probably be useful in this case.

Another responder mentioned the importance
of nailing down the format of a value.

I suggest the following for floating point values:
A fixed point value optionally followed by an integer exponent.
A 0x or 0X leading the digits in the fixed
point value would indicate a radix of 16.
Just a 0 would indicate base 8.
Otherwise the radix would be 10.
The integer exponent, if any, would indicate
multiplication by a power of the radix.
The exponent itself would be an e or E followed by a decimal integer.

I also suggest that the format include explicit rational numbers.
An explicit rational number would be a floating point value
representing an integer followed by a slash followed by
another floating point value representing an integer.
In most cases, a floating point value representing an integer
would be written with neither decimal point nor exponent.
2/3 is a allowed and so is 7/03e9 .

When an exact representation is allowed, one need not vary
the representation depending on the precision of the machine.

Allowing rational numbers is probably as
far as one should go in that direction.
Allowing arbitrary algebraic numbers would be a bit much.
Did someone mention trig functions?

> I row-num row-name

How about
R row-name row-num ?

> J col-num col-name

C col-name col-num ?

This one really doesn't like I and J.
They often look too much alike,
so I often use J and K.
This of course causes joy when I need to
compare my work with that using I and J.

I reversed the order of names and numbers to ensure
that they would be syntactically distinguishable
from declarations of free rows and cols even if a
row or column is named F.
Naming rows and columns with NR and NC lines would also work.

You might also consider what you want to allow in names.
At the very least, I'd recommend disallowing
nongraphic characters and leading digits.

-- 
Mike   address@hidden
"Nothing says it like words if you know how to use them."
                    --  the Professional Organization of English Majors