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

[Reginald Beardsley]

I'd like to make a comment on this if I may.

Very often I have needed to supply the results of my work to a client in a form 
that can be easily loaded into Excel. That's what they are comfortable using to 
examine and display the results.  Whenever I have needed to do that, I have 
simply written a quick awk script to handle the task.

However, many are not so facile w/ awk.  So long as it doesn't break anything I 
think there is considerable merit in being able to accommodate the needs and 
wishes of others with a minimum of fuss.

I'm currently using awk to create the input to glpsol and another awk script to 
reduce the output to usable form.  Ultimately I will code a C application using 
the library.  But for my initial R&D work I find many small steps and ASCII 
files far easier to work with.

Many thanks to all for such a first class package.  The code is some of the 
best, if not the best, I've ever seen.  I've been sole support for several 
million lines of other people's code over the years.  So it's a real treat to 
see something so well written.

Have Fun!
Reg


--- On Thu, 1/13/11, Xypron <address@hidden> wrote:

> From: Xypron <address@hidden>
> Subject: Re: [Help-glpk] adding --csv output
> To: "Kevin Hunter" <address@hidden>
> Cc: "GLPK Help List" <address@hidden>
> Date: Thursday, January 13, 2011, 2:25 PM
> Hello Kevin,
> 
> thank you for the submitted enhancement of GLPK.
> 
> I compiled the patched version of GLPK-4.45 without
> problems. Running the following command
> ./glpsol -m tsp.mod --csv test.csv -o test.txt
> resulted in the appended files.
> 
> 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
> 
> test.csv:
> Columns:,480
> test.txt:
> Columns:    480 (240 integer, 240 binary)
> 
> >> 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.
> 
> 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.
>    * Is there information you are missing in
> the API but see in the file?
>    * Is a GLPK binding missing for the
> language of the target application?
> 
> >> 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.
> 
> Best regards
> 
> Xypron
> 
> 
> Kevin Hunter wrote:
> > Hullo Andrew, List,
> > 
> > I had need of an unambiguous version (for machine
> parsing) of the output provided by the glp_print_*
> functions.  Consequently, I've created an equivalent
> set of glp_csv_* functions.  With this patch, one can
> use a --csv <file> flag:
> > 
> > $ glpsol --lp test.lp --csv solution.csv
> > 
> > This patch adds three glp_csv_{sol,ipt,mip} functions
> and a couple of miscellaneous helper functions to the
> glpk-4.45 tarball.
> > 
> > I'm rather new to GLPK's code base, but I think I've
> my ducks in a row.  Specifically, Xypron, if you have
> some time, I would much appreciate a code review.
> > 
> > Thanks, and I hope this proves useful to others.
> > 
> > Cheers,
> > 
> > Kevin
> > 
> > 
> > _______________________________________________
> > Help-glpk mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/help-glpk
> >    
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Help-glpk mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-glpk
>