Hello Jeffrey The quick answer is "not hard at all".
RECOVERING JUST THE VALUES I suggest starting with the 'glpsol' option: --write filename : write solution in plain text format The first thing to determine is whether the problem is pure-LP or MIP. If not already known, this can be undertaken by counting the number of values in line two: three values indicates a pure-LP and two indicates an MIP (whether this is robust in the event of the solver returning failure or similar needs confirming). The next step is to parse the entire file according to the formatting rules for the underlying API call: pure-LP problem : 'glp_write_sol' MIP problem : 'glp_write_mip' Consult the API manual for the actual details here. Parsing should be straightforward using double type arrays and matrices from R, in conjunction with the m x n information previously captured from line one. If one wants the LP-relaxation solution for an MIP problem, then I guess one would need to subsequently deploy '--nomip' and repeat the parsing task. [As a suggestion to Andrew, it might be cleaner for the '--write' option to state something like "LP" or "MIP" in the opening line to unambiguously indicate the problem class -- or perhaps even give a finer resolution, for instance "mixed-integer", "mixed-01", etc). Note too that the now depreciated 'lpx_get_class' call used to provide at least some of this information.] The R command that could be used to read in the raw data is 'readLines()': data <- readLines(filename) # default is to read all lines <- length(data) message("lines read : ", lines) if ( lines == 0 ) warning("no lines read") Also useful might be 'strsplit()', 'unlist()', and 'as.numeric()' for string to number coercion. OBTAINING MORE INFORMATION It would also be quite possible to parse the results from the existing 'glpsol' option: --output filename : write solution in printable format Parsing this data would take more work but would also reveal more information, such as row and col labels (names). The current 'glpsol' practice of wrapping the output at text column 65 also makes the parsing task a little more awkward (as occurs in the presence of long row and col labels) but not impossible. [Perhaps a new 'glpsol' option might help here: --meta filename : write problem metadata in parsable key/value format This option would output the problem name, row and col labels and so-forth for use in conjunction with option '--output'. It could equally apply to unsolved and solved problem instances, but with the current solution status in the latter case.] READING THE PROBLEM The flip question (although not stated) is that of recovering the original problem using R via an exported MPS, CPLEX, or (not currently documented and/or fully implemented) OPB format. R itself already supports LP importation as part of either its core distribution or via contributed code. Here are some packages although I have no idea as to their respective statuses, except I think 'Rglpk' has yet to catch up with the new APIs: package 'Rcplex' - R interface to the CPLEX optimization library package 'linprog' - linear programming / optimization package 'Rglpk' - high level R interface to the MPS and CPLEX_LP reader of the GNU Linear Programming Kit (GLPK). CLOSURE I don't use 'glpsol', but I imagine that some modeling tasks are adaptive and that this adaptation might more easily take place in an external scripting environment than in MathProg. Hence, script-friendly status and results recovery could be of benefit here. with best wishes to all Robbie ps: Andrew: the "glp_write_sol" on page 99 of the 4.41 API manual should read "glp_write_mip". ------------------------------------------------------------ To: Robbie Morrison <rob...@actrix.co.nz> Subject: Re: [Help-glpk] Need help on interval planning constraint From: Jeffrey Kantor <kanto...@nd.edu> Date: Tue, 22 Dec 2009 16:58:32 -0500 ------------------------------------------------------------ Robbie, How hard would it be to write a standard import script for R? That is, something to take glpsol's standard report and digest it into something that could be directly manipulated in R. On Tue, Dec 22, 2009 at 3:51 PM, Robbie Morrison <rob...@actrix.co.nz>wrote: > > > > Hello GLPK users > > > > A plug for R : I use R for visualization and like it very much. The > > environment is comparable with Matlab, but the language is nicer. I > > either run it from a shell or from within Emacs (recommended only if > > you know and love this editor) using the ess-mode. > > > > with best wishes, Robbie --- Robbie Morrison PhD student -- policy-oriented energy system simulation Technical University of Berlin (TU-Berlin), Germany University email (redirected) : morri...@iet.tu-berlin.de Webmail (preferred) : rob...@actrix.co.nz [from IMAP client] _______________________________________________ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk