[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-glpk] Processing glpsol output with R (was: Need help on inte
Re: [Help-glpk] Processing glpsol output with R (was: Need help on interval planning constraint)
Tue, 29 Dec 2009 09:34:44 +0700
Hi Robbie and Jeffrey,
R package, R Graphics and R Geo (maptools) are very GLPK / MathProg
output friendly. In the days few days, I was able to use some of the
difficult graphing problems I had. I even implemented joining tables
(LP result) in shapefile and rendering the maps using R Geo (spatial
R) i.e. maptools.
R package has library(foreign).
It reads and writes -, dbf, csv, dat and other format. We can read
directly from GLPK / MathProg in this format.
set A, set B, set C, Param1, Param2
No need to reformat the tables output by MathProg.
forests <- read.csv("C:\\Down2\\R_forestmgt\\forest_cut.csv")
p <- ggplot(forests, aes(Period, Cut_Age)) + geom_point(colour =
"brown", size = 1)
p + facet_wrap(~ Croptype, ncol = 2)
The forest_cut.csv table has this format.
set A, set B, Param1, Param2
Period, Croptype, Age, HarvestArea
Another note: GUSEK runs R-package perfectly.
On 12/29/09, Robbie Morrison <address@hidden> wrote:
> 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
> 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).
> 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
> ps: Andrew: the "glp_write_sol" on page 99 of the 4.41
> API manual should read "glp_write_mip".
> To: Robbie Morrison <address@hidden>
> Subject: Re: [Help-glpk] Need help on interval planning constraint
> From: Jeffrey Kantor <address@hidden>
> Date: Tue, 22 Dec 2009 16:58:32 -0500
> 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.