[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-glpk] adding --csv output
Re: [Help-glpk] adding --csv output
Thu, 13 Jan 2011 18:10:12 -0500
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) 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:
Status: INTEGER OPTIMAL
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
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.