[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] Fixing Numerical Instability Problems

Subject: Re: [Help-glpk] Fixing Numerical Instability Problems
Date: Tue, 22 Mar 2011 01:59:50 -0500

On Fri, 18 Mar 2011 22:43:03 +0300
 Andrew Makhorin <address@hidden> wrote:
> > It may take a little while to get the "glp_write_prob" output
> because I
> > don't access to the computer resources needed to re-run these
> examples
> > (they were run by a colleague on a parallel research cluster) but I
> do
> > have a printout the LP coefficient matrices that caused a problem.
>  I'm
> > including a number of these instances.  Note that I'm not printing
> out
> > the last row, the last column, nor the r.h.s. because they are the
> same
> > for every LP of a given size.  The last column contains a -1.0 in
> every
> > entry except the lower-right corner entry which is a zero.  The
> last
> > constraint row contains a 1.0 in every entry except the lower-right
> > corner which again is a zero.  Every constraint row except the last
> is
> > <= 0 (in glpk form, you add an artificial variable and have the
> > constraint = 0).  The last constraint is = 1.0.  All of the output
> was
> > generated by the application program except for two lines that were
> > output by glpk saying that it was unable to factorize the basis
> matrix
> > and that basis recovery hadn't been implemented yet.  The fifth and
> > seventh LPs listed below were the only two in which there wasn't
> two or
> > more identical constraint rows.  Sorry about the mail facility word
> > wrapping the longer constraint rows; there doesn't seem to be a way
> to
> > avoid it.  If this information isn't sufficient and you really need
> to
> > see the output from glp_write_prob, let me know and I'll get that
> to
> > you when I can.  Thanks very much for your time.
> It seems to me that the error in solution is caused by some other
> reason, at least not by linearly dependent rows. Since all your
> instances are of small size, I'd recommend the following: remove any
> calls to glp_scale_prob, and every time you need to solve a newly
> generated lp instance, call glp_std_basis and then glp_simplex with
> the
> lp presolver disabled (don't forget to check the return code from
> glp_simplex). If the error will not disappear, please post me the
> instances written in cplex lp or glpk format. Thanks.

removing the call to glp_scale_prob fixed the problems!  When we
initially ran into these error, we made two changes; reset tiny numbers
that are effectively zero to exactly zero and add the call to
glp_scale_prob.  Removing the scaling and leaving in the resetting of
"effective zeroes" solves the problem. :-)

Thanks for your suggestions.

-- Glenn C. Rhoads

reply via email to

[Prev in Thread] Current Thread [Next in Thread]