Hi Rafael,
Sorry for a delay in my response.
> I just tried GLPK 4.30 and it seems that the bug is still present (see
> below). Am I doing something wrong, or is the bug really not fixed yet?
The bug really was not fixed in 4.30, because it appears due to
excessive round-off errors in other rou
[ This is in the context of:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490288 ]
* Andrew Makhorin <[EMAIL PROTECTED]> [2008-07-12 18:06]:
> Saturday, July 12, 2008, 5:56:31 PM, you wrote:
>
> > Does this mean that the problem is in the formulation of that specific
> > example or is it a
Hello Gernot,
The modified example suggested by Andrew
results in another failed assertion
Assertion failed: ipp != ipp
Error detected in file glpipp02.c at line 801
even in cases where the program without --cuts succeeds.
a bug has been fixed in glpipp02.c in version 4.29 of GL
> It seems that the behaviour of glpsol and the mip solver depend on
> the computer architecture
Yes, because glpk uses inexact (floating-point) arithmetic.
> and that the program doesn't always catch
> overflows or underflows.
Most probably the failure is caused by excessive round-off errors,
[ I'm a colleague of Ingo Feinerer working on the same topic. ]
It seems that the behaviour of glpsol and the mip solver depend on
the computer architecture and that the program doesn't always catch
overflows or underflows. The modified example suggested by Andrew
results in another failed asserti
* Andrew Makhorin <[EMAIL PROTECTED]> [2008-07-12 18:06]:
> Saturday, July 12, 2008, 5:56:31 PM, you wrote:
>
> > Does this mean that the problem is in the formulation of that specific
> > example or is it a bug in GLPK? If the later is the case, are you
> > planning to fix it?
>
> It is a bug i
Saturday, July 12, 2008, 5:56:31 PM, you wrote:
> * Andrew Makhorin <[EMAIL PROTECTED]> [2008-07-12 16:06]:
>> The failure appears due to insufficient robustness of the glpk mip
>> solver. It is mainly caused by unbounded integer variables (x1 and x2
>> have no upper bound) having relatively larg
* Andrew Makhorin <[EMAIL PROTECTED]> [2008-07-12 16:06]:
> The failure appears due to insufficient robustness of the glpk mip
> solver. It is mainly caused by unbounded integer variables (x1 and x2
> have no upper bound) having relatively large coefficients in the
> constraint that leads to exces
Saturday, July 12, 2008, 12:35:26 PM, you wrote:
> package glpk
> tags 490288 confirmed upstream
> thanks
> * Ingo Feinerer <[EMAIL PROTECTED]> [2008-07-11 12:00]:
>> Package: glpk
>> Version: 4.11-1
>> Severity: normal
>>
>>
>> The following linear program triggers an assertion and stops the
package glpk
tags 490288 confirmed upstream
thanks
* Ingo Feinerer <[EMAIL PROTECTED]> [2008-07-11 12:00]:
> Package: glpk
> Version: 4.11-1
> Severity: normal
>
>
> The following linear program triggers an assertion and stops the program
> without a proper solution:
>
> var x1 integer;
> var
Package: glpk
Version: 4.11-1
Severity: normal
The following linear program triggers an assertion and stops the program
without a proper solution:
var x1 integer;
var x2 integer;
minimize objective : x1 + x2;
s.t. constraint : (8^4 - 1) * x1 - 8^4 * x2 = 0;
s.t. x1NotNegative : x1 >= 1;
s.t.
11 matches
Mail list logo
