[Top][All Lists]

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

Re: [Help-glpk] adding --csv output

From: Kevin Hunter
Subject: Re: [Help-glpk] adding --csv output
Date: Thu, 13 Jan 2011 18:10:12 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101208 Thunderbird/3.1.7

At 3:25pm -0500 Thu, 13 Jan 2011, Xypron wrote:
The csv file contains just about the same information that is the txt
file. I observed two differences:


Heh.  I clearly missed a detail.  :-)

Columns: 480 (240 integer, 240 binary)

Same here.  Missed detail.

I had need of an unambiguous version

A parser may be easier to write for CSV then for a fixed field
length file. The text file is unambiguous too.

True enough. I can visually tell from the output what number is with which column, but I've so far been unable to successfully write a good enough parser.

Actually, I'm now unable to create an example that is ambiguous. I seem to recall some inputs that would create lines that spanned two lines, while others wouldn't (I can recreate this with a long enough variable name), but I'm now unable to reproduce the numbers that exceed column width. glpapi11.c hasn't changed much in a few iterations so I wonder how I was able to create (about 6 months ago, maybe) the numbers that exceeded column boundaries.

So, now that it's pointed out to me, I agree that the text file is unambiguous, but it seems to me that a CSV version doesn't hurt, and is much easier to parse.

I would like to better understand the user benefit of the patch:

* Why do you prefer to write a file and do not use the library,
   to avoid unnecessary file handling altogether? This might have
   required less code than your patch.

- Sometimes, just as Reginald pointed out, I would like to do
  manipulations of the results with outside tools.  Using the CSV
  "standard", I can immediate use a wide berth of tools (e.g.

- Sometimes I need to get back to the results many days later.
  If I don't do the manipulations "right now", I have to rerun
  the solve.  I suppose I could use glp_read_sol, but I like
  being able to access the data outside of GLPK routines.

- If I'm working with custom code, I could use the GLPK language
  binding, but then I have to also have GLPK on the machine on
  which I'm working -- something I can't guarantee for certain
  workflows.  Having CSV parseable output increases my

- If working with custom code, it becomes easier to use standard
  CSV handling libraries than to write a fairly one-off handling
  of GLPK specifics.

- Often, I'm not able to directly access the GLPK API.  I *must*
  run GLPK via the command line.

- In other situations, I am limited to LP inputs.  I can't use

* Is there information you are missing in the API but see in the

The opposite, actually. I would like more information in the glp_print_* and glp_csv_* outputs, like the object coefficient range, object value at break point, and limiting variable. I just haven't figured those out yet.

Generally, however, I can only rarely use the API. CSV output would generally be a big help for me.

I would much appreciate a code review.

glp_csv_mip seems to be short of a copy of glp_print_mip. Enabling
xfprintf to write in CSV format depending on flag type in structure
XFILE could be a viable alternative to replicating a lot of code.
Gzipped files are already handled using this flag.

I like it. My patch was more of a "Here's working code, let's improve it," because vaporware is not so great for getting the ball rolling. I was painfully aware that they were little more than copies as I was writing them, but I figured having a more knowledgeable person suggest a route was the better course of valor. What XFILE flag would you suggest?

#define FH_CSVO 0x33  /* csv output */   // perhaps?

Would further work on this patch be appreciated, or, more appropriately, accepted? Having CSV output would really help to more elegantly streamline a couple of my workflows and needs.



reply via email to

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