> 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. _______________________________________________ Bug-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-glpk
