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: Nigel Galloway
Subject: Re: [Help-glpk] A new text-based data format for GLPK
Date: Sun, 3 Jan 2010 15:31:37 +0100

Or (more sensibly?) XML can be converted to formatted text for those who 
require it.

The following may be interesting(Displaying Linear Programs and Their Solutions 
With XML and SVG):

http://portal.acm.org/citation.cfm?id=1082118


> ----- Original Message -----
> From: "Robbie Morrison" <address@hidden>
> To: "GLPK help" <address@hidden>
> Subject: [Help-glpk] A new text-based data format for GLPK
> Date: Thu, 31 Dec 2009 16:44:28 +0100
> 
> 
> 
> 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]
> 
> 
> 
> 
> _______________________________________________
> Help-glpk mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-glpk

>


-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

Powered by Outblaze




reply via email to

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