[Bug-glpk] Re: GLPK on 64 bit Linux

[Andrew Makhorin]

> I #8217;m including bug-glpk here as this is potentially a bug, but it
> could be something we are doing wrong.

> We are using GLPK with Java (glpk-java-1.0.5), but to date have been
> using it in a 32 bit Linux environment and it #8217;s been fine (apart
> from crashes which we put down to the fact it #8217;s not thread safe)

> Now we are trying to use it in a 64 bit Linux environment and
> encountering some strange issues and I #8217;m just wondering if
> anybody else has encountered these and how we might solve it.

> To move to 64 bit, we recompiled the C code on 64 bit to produce a new
> shared object linked to it. It runs and executes no problem. For most
> of our inputs, it gives the same outputs as before, save for some very
> small diffs which I put down to the different floating point rounding.

> However, there are cases where a few of the numbers differ by amounts
> that cannot be put down to rounding. We have sometimes a fraction like
> .8xxx going to 0, or we have large numbers differing by 10-15%. Again,
> this is only in very few of the output variables out of quite a lot
> (all the others match fine) and many sets of inputs have no problem
> but it #8217;s enough to pose an issue if it goes wrong for even some
> of our inputs.

> We have dumped the inputs to a .dat file to confirm the inputs are the
> same going in for both 32 bit and 64 bit. It #8217;s the same Java
> software calling the solver so this should be the case.

> Does anybody know about such issues with 64 bit and the cause? Is
> there some particular compile flags or switches we need to use? Is
> there anywhere on the net a confirmed working binary version of GLPK
> for Java on 64 bit?

> If this is completely new and you would like to investigate, what
> would you need to be supplied with as a test case to look into the
> problem?

Thank you for your report.

Are the optimal objective values found by the 32- and 64-bit version
of the solver identical or close to each other? If so, this is not
a bug. If your lp/mip instance has multiple optima, it may happen that
the 32-bit glpk solver finds one optimal solution while its 64-bit
version finds another solution, which is optimal too. This is normal.