On Apr 3, 2011 3:23am, Marcelo Pinto <address@hidden> wrote:
> Before I propose that small patch, I had exchanged some emails with > Andrew Makmorin (the creator of GLPK) and he made the following > comments
> PS: I'd like to note that your code uses obsolete glpk api routines > (prefixed with lpx_). If you have a time and wish, I could help you to > reimplement the code using the standard glpk api. I'm not familiar with > Octave internals, however, I could rewrite the glpk function.
Hi Marcelo. Of course any help is appreciated, but if you had the chance to look at what __glpk__.cc becomes when you apply the patch I proposed, you have probably already seen that lpx_ functions are used only in two occasions.
In one to save the problem in text format. In this case, lpx_print_prob(x,y) is can indeed be substituted with glp_write_lp(x,NULL,y). If somebody thinks it would really make a difference, I can fix that right away.
In another to set the parameters. Here lpx_set_int_parm and lpx_set_real_parm cannot really be substituted with other functions.
Anyway, if you're in contact with Andrew already, there is one improvement to GLPK itself that would have a good repercussion on the patch. The code that takes care of generating the conflict graph and of finding the maximum weight clique outputs text to the console disregarding of whatever msglev you passed. Simply there's no control in glpios8.c. I think this needs to be fixed. My personal opinion is that having information on how the conflict graphs looks like or on the the clique cut internals is only interesting when you want pedantic reports on what's going on and therefore that it shouldn't come out for msglev msglev < GLP_MSG_ALL. I did what I could in the patch to suppress such output when msglev is 0, but the clean thing would be to control the output from GLPK itself as in many other routines.