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

[Kevin Hunter]

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:
>
> test.csv:
> Status:,UNDEFINED
> test.txt:
> Status: INTEGER OPTIMAL

Heh.  I clearly missed a detail.  :-)

> test.csv:
> Columns:,480
> test.txt:
> 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.
  Excel/Calc).

- 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
  flexibility.

- 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
  GMPL.

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

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.

Thanks,

Kevin