[Help-glpk] RE: GLPK on 64 bit Linux

[Hammond, Paul]

Hi Andrew,

Thanks for replying.

Yes you're right, a given input resource may be allocated differently and is 
the case. But one thing that should remain constant though is the totals, what 
I'm talking about is that the totals of the allocations at the end of a given 
input do not equal that input.

By way of illustration, take the often quoted example where the farmer is 
allocating his land to grow wheat or barley subject to constraints. In the 
output results, even if there are multiple optima, all the land should be 
allocated to either wheat or barley, but I find cases where the total land in 
the output is less or greater than the amount coming in, and it's too great to 
be a rounding error.

Now my resource allocation problem is clearly different than the simple example 
above, I have many different resources to be allocated subject to more 
constraints, but the problem I have is essentially the same as this analogy.

Paul 

-----Original Message-----
From: Andrew Makhorin [mailto:address@hidden 
Sent: 25 March 2010 13:56
To: Hammond, Paul (IDEAS)
Cc: address@hidden; address@hidden
Subject: Re: GLPK on 64 bit Linux

> 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.



--------------------------------------------------------------------------
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.