bug-glpk
[Top][All Lists]
Advanced

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

[Bug-glpk] minimization flag ignored by 'glp_simplex' (GLPK 4.25)


From: Robbie Morrison
Subject: [Bug-glpk] minimization flag ignored by 'glp_simplex' (GLPK 4.25)
Date: Wed, 25 Jun 2008 18:50:47 +0400

Hello Andrew and other API users

I am using GLPK 4.25 (because my transition to 4.28 has
not yet been completed for the reasons outlined in my
posting on 06-Jun-2008).

I am currently experiencing a problem getting
'minimization' to stick, even though I set this flag
explicitly with 'glp_set_obj_dir' and 'glp_get_obj_dir'
returns 'GLP_MIN' before and after the solver call.

I have some small test LPs (nodal electricity markets
as it happens), ranging in size from 4x4 to 100x70, and
the problem only occurs when I invoke 'glp_simplex'.
If I switch to 'lpx_interior' instead, everything works
EXACTLY as expected.

The 'glp_simplex' problem, however, ALSO evaporates
when I invoke my application with the 'valgrind' memory
checker.  The reverse is also true.  If I set
'maximization', my application runs along fine by
itself -- yet under 'valgrind' it gives me
minimization.  Please note that I have very carefully
double checked this behavior, because it seems so
counter-intuitive.  And apart from this unusual
side-effect, 'valgrind' never reports memory errors or
leaks.

I have not experimented with 'glp_intopt', but could
easily do so.

Initially I thought the problem was related to a
third-party call to 'memmove'.  But further trials show
this particular library call arises from std::vector
and not GLPK.

My application is written in ISO C++ and (this part
anyway) does not utilize anything more than the C++
Standard Library and GLPK.

Use of the LP presolver via "lpx_set_int_parm(prob,
LPX_K_PRESOL, 1)" makes no difference to this unusual
behavior.  Neither does reapplying the 'minimization'
flag a few statements before the solver call, rather
than immediately after the GLPK problem instance was
created.

I have only investigated the problem at this stage and
have not attempted any significant debugging.  But it
seems that GLPK is not tracking its directionality flag
properly.

For the record, my system is Linux 2.6.17 / i686 (Intel
Celeron) / Ubuntu GNU/Linux 6.10 (edgy) x86 released
Oct-2006.  The compiler is g++ (GCC) 4.1.2.  My last
routine upgrade (via APT) was 14-Apr-2008.

I realize that, as a work around, I can multiply my
objective function by minus one, or continue to run my
application under 'valgrind', or use the 'lpx_interior'
solver instead.

Please let me know if anyone needs more info.  I could
write the problem out in pure GLPK API form (like
'sample.c') if need be -- but cannot guarantee that the
problem would persist.  Or I can easily email the
requisite subset of my application source code.

My only other thought is that I use repeated calls to
'glp_load_matrix' and I pass in the addresses of the
first element of 'std::vector's -- instead of using
C-style fixed-length arrays.  But both actions should
be completely legitimate.  Regarding the use of STL
vectors as ordinary arrays, see Josuttis (1999 p155).
Moreover I did experiment with 'reserve'ing excessive
memory for my vectors to force them to not reallocate,
but again this made no difference.

If some help is needed with bug hunting or patch
testing, please let me know.  I should be able to turn
such requests around in a couple of days or perhaps
less.

REFERENCES

  Josuttis, Nicolai M.  1999.  The C++ Standard
    Library : a tutorial and reference.
    Addison-Wesley, Boston, USA.  ISBN
    0-201-37926-0.

[note to self: r1660, 'alone-lmp.cc']

best wishes to all
---
Robbie Morrison
PhD student -- policy-oriented energy system simulation
Technical University of Berlin (TU-Berlin), Germany
University email (redirected) : address@hidden
Webmail (preferred)           : address@hidden
[from IMAP client]









reply via email to

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