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

[Michael Hennebry]

On Wed, 28 Jul 2004, Andrew Makhorin wrote:

> I don't think that using names is essential. Even if names are used,
> as in mps, and even they are meaningful, nobody is able to "read"
> (i.e. to understand) a constraint matrix having more than several tens
> of rows and columns (unlike the assembly code which is more mnemonic
> than symbolic). Under readability I understand that one is able to
> identify which column is non-negative, which row is equality constraint,
> etc., not more.

If that is what you deem sufficient human-readability,
then you made the right decision.

The skill with which one generates names greatly affects readability.
If I see variable X[barn90,pig1047] mentioned in row horse_waste_limit,
I can tell that something is wrong.
I note that neither of those names is allowed by MPS.
Sometimes I've gone to considerable work
to generate meaningful MPS-allowed names.

> I do not pretend the proposed format to be "state-of-the-art". Its
> prototype is dimacs formats for coding some classes of combinatoral
> problem instances. Files in such formats can be easily created and
> processed even in fortran 77 (and even in Algol 60 :+).

FORTRAN can't do symbol tables?

I'm not sure whether you want the new format to displace MPS.
If so, allowing symbolic references to rows and columns
would help it gain acceptance.

[regarding rationals, e.g. 2/3 != .666666667]

> >I think that the difference would show up for 64-bit doubles.
> >If double is 128 bits, I'm sure the difference would show up.
>
> Even using other C compiler (and even changing optimization option for
> the same C compiler) involves the difference. So, coding data as

Even really poor readers read integers correctly
and convert them to floating point correctly.
The only difference to be expected would result
from differences in performing the division.
If IEEE arithmetic is used,
the only difference allowed would be in the last significant bit.
That would be determined by the rounding mode, not the optimization option.

Another issue is that a solver's margin for floating point error
might be adjusted for the precision of the platform.
In that case, writing data for one precision and
having it read on a platform with a higher precision
might prevent a system of equations from having an acccepted solution.

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