[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-glpk] interrogating (and emptying) GLPK glp_prob instances
From: |
Andrew Makhorin |
Subject: |
Re: [Help-glpk] interrogating (and emptying) GLPK glp_prob instances |
Date: |
Fri, 6 Jun 2008 15:30:01 +0400 |
> I am writing some code to display the state of a GLPK
> 'glp_prob' instance using machine-generated HTML. The
> code is complete and I will post details and some
> sample output back to this list after I resolve a
> couple of small questions, namely:
> Can I find out what kind of solvers ('glp_simplex',
> 'lpx_interior', 'lpx_intopt', 'glp_intopt') have been
> run on a particular problem instance by interrogating
> that instance -- or does the client code have to keep
> track of the solver calls it makes?
> Can I find out if the problem has changed since the
> solver last ran. I suspect not (and thereby suggest a
> new status variable 'GLP_MOD' meaning "the problem has
> subsequently been modified" .. or perhaps even a new
> status function 'glp_get_prob_status' if you want to
> retain access to the now stale solution status
> information).
Currently such information is not available. However, it seems to be
reasonable to add such flags.
> Finally, what is the best way to empty a problem object
> of input data -- I currently remove all the rows and
> cols but is there a more elegant method?
In 4.29 I added api routine glp_erase_prob which erases the problem
object content as if the object were just created by glp_create_prob.
But in principle your way is normal; glp_erase_prob does the same.
> And does this
> mean I can rebuild a similar problem of identical size
> and have it warm start?
Yes. If you provide appropriate statuses of rows and columns,
you can then use warm start.
Andrew Makhorin
PS: Robbie, thank you very much for your suggestions concerning
glpk api documentation.