bug-glpk
[Top][All Lists]
Advanced

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

[Bug-glpk] GLPK on 64 bit Linux


From: Hammond, Paul
Subject: [Bug-glpk] GLPK on 64 bit Linux
Date: Thu, 25 Mar 2010 15:56:16 +0300

Hi,

 

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?

 

Thanks,

 

Paul

 

 









NOTICE: If received in error, please destroy, and notify sender. Sender does 
not intend to waive confidentiality or privilege. Use of this email is 
prohibited when received in error. We may monitor and store emails to the 
extent permitted by applicable law.





 

Hi,

 

I’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’s been fine (apart from crashes which we put down to the fact it’s not thread safe)

 

Now we are trying to use it in a 64 bit Linux environment and encountering some strange issues and I’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’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’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?

 

Thanks,

 

Paul

 

 


NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.


reply via email to

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