help-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Robbie Morrison
Subject: Re: [Help-glpk] A new text-based data format for GLPK
Date: Fri, 08 Jan 2010 21:09:54 +0100
User-agent: Thunderbird 1.5.0.14ubu (X11/20080306)

Hello all

Some more thoughts on structured text and XML.

I use a C++ class I named 'GlpkViz' which interrogates
a 'glp_prob' GLPK problem object and generates
table-based HTML.  In fact I find this visualization
*extremely helpful* when developing the code which
progressively builds my underlying LP models.

On the other hand I often use 'grep' 'sed' and 'gawk'
in 'bash' scripts and find these utilities very
workable at times.  So I quite like UNIX plumbing as
a concept.

Regarding the DIMACS-like format proposed by Andrew, it
looks completely workable (posted Thu, 7 Jan 2010
15:10:12 +0300).  A few comments follow:

Regarding the use of "c" as a comment prefix.  Not
being a FORTRAN programmer, I would prefer a '#' or
another non-alpha character to introduce comment lines.
But that may well reduce the portability of the format.
Moreover, are trailing comments to be supported or, at
least, admissible but ignored?

I guess that some solution fields will be proposed in
due course.  :)   Will we be able to control the numerical
format and precision?  And close-to-zero rounding?

Information on problem status, solution status,
solver settings, and solver performance might also be
considered.  Or this pushing the DIMACS concept to
something that would be better addressed with XML?

My HTML visualization, for instance, reports values and
reduced costs for every row and col.  Plus any other
scrap of information I can recover via the GLPK APIs.
It also highlights a number of potential data problems
(missing values and so forth) as defined by me, with an
orange cell boarder.  It also displays things like the
number of iterations if appropriate.  The question therefore
arises as to how much of this information would be present
or absent in whichever new format is chosen.

(I would offer 'GlpkViz' to the GLPK codebase but it is
effectively debarred on basis of not being C.)

As far as standardization goes, it would appear that
DIMACS is better established than the two LP XML
dialects presented thus far.  Or am I misinformed?

Of course, both the DIMACS format and XML generation
can mutually coexist, so I guess we are really talking
about development priorities.

Unfortunately I am not in a position to offer to code
up any of this (although I am willing to test), so my
comments will necessarily remain advisory.

As always, many thanks to Andrew for the well focused
effort he puts into maintaining and extending GLPK for
us all.

with best wishes
Robbie
---

>> ------------------------------------------------------------
>> To:          address@hidden
>> Subject:     RE: [Help-glpk] A new text-based data format for GLPK
>> Message-ID: <address@hidden>
>> From:       "Nigel Galloway" <address@hidden>
>> Date:        Fri, 8 Jan 2010 16:39:08 +0100
>> ------------------------------------------------------------
>>
>
> Thanks for the reference. I have used osi for my
> programming api for a while now and this will be a good
> addition.
>
> Taken together with the paper Displaying Linear
> Programs and Their Solutions With XML and SVG this
> makes a good case for an XML format.
>
> Formatted text is really somthing which gives
> instructions to notepad on how to display something
> which is humanly readable. Missing from the OS
> distribution is something to make the OSrL humanly
> readable in a web browser. Perhaps OS should include
> some example xsl files for client side display. I would
> probably use php and do the final stage server side as
> the more modern approach. Without these Robbie has a
> point that the output is less immeadiatly humanly
> readable than the formatted text.
>
> Obviously a web browser provides a much richer display
> environment than notepad. Font Style, Colour, and
> Graphics as well as layout.
>
> In addition XML is extensible. That is tags can be
> added to include new information as required, without
> affecting any tools already using the format. gawk is a
> good tool for transforming formatted text, but if the
> format is modified even slightly its unlikly that any
> script written in gawk will still produce good results.
>
>> ----- Original Message -----
>> From: "Robert Fourer" <address@hidden>
>> To: address@hidden
>> Cc: "'Nigel Galloway'" <address@hidden>
>> Subject: RE: [Help-glpk] A new text-based data format for GLPK
>> Date: Sun, 3 Jan 2010 10:16:19 -0600
>>

[snip - previoius traffic]

---
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]






reply via email to

[Prev in Thread] Current Thread [Next in Thread]