[Help-glpk] A new text-based data format for GLPK

[Robbie Morrison]

Hello Andrew, GLPK users

> ------------------------------------------------------------
> To:          Robbie Morrison <address@hidden>
> Subject:     Re: [Help-glpk] Processing glpsol output with R
> Message-ID: <address@hidden>
> From:        Andrew Makhorin <address@hidden>
> Date:        Tue, 29 Dec 2009 20:50:17 +0300
> ------------------------------------------------------------
>
> Hi Robbie,
>
>> > [As a suggestion to Andrew, it might be cleaner for the
>> > '--write' option to state something like "LP" or "MIP"
>> > in the opening line to unambiguously indicate the
>> > problem class -- or perhaps even give a finer
>> > resolution, for instance "mixed-integer", "mixed-01",
>> > etc).  Note too that the now depreciated 'lpx_get_class'
>> > call used to provide at least some of this information.]
>
> Thank you for the suggestion.
>
> I think that it is reasonable to include in glpk some api
> routines to read and write lp/mip instances as well as
> basic/interior-point/mip solution from/to a text file in a
> more convenient format, which would include row/column
> names.  A DIMACS-like format seems to me most suitable,
> because it allows easily using standard text utilities like
> sed, gawk, etc.  Using XML seems to me much more tricky and
> much less convenient for processing out of glpk.
>
> Andrew Makhorin

I took the liberty of opening a new thread!

I agree that structured text, when compared to XML, can be
easier for humans to read (particularly for test instances)
and that text is certainly more convenient to interpret and/or
modify using basic utilities and common scripting languages.

Indeed XML should really be parsed and it is considered very
poor form to apply grep and friends to XML.

The conversion of structured text to XML always remains an
option for those who require XML.

With regard to the DIMACS-like format, I guess you are
referring to their CNF or conjunctive normal form.

  http://en.wikipedia.org/wiki/Conjunctive_normal_form

I cannot comment on the appropriateness of this choice,
beyond to say that the format seems to be current and that
other projects are offering support for it.  It also appears
that several stand-alone format translators are available.

Having experimented with XML support in C++ applications,
I acknowledge that the coding overhead is higher.  In
addition, you would need to select a suitable GPL'ed
C-based XML library for the XML option.

Other people have views ??

with best wishes
Robbie
---
Robbie Morrison
PhD student -- policy-oriented energy system simulation
Technical University of Berlin (TU-Berlin), Germany
University email (redirected) : address@hidden
Webmail (preferred)           : address@hidden
[from IMAP client]