Re: One-off error in the MIP solver?

[STEVE VESTAL]

IEEE float has different representations for -0 and +0.  Any chance that might 
be involved in the computations in some way, even though MIP?  What happens 
with e != 0?

> On 01/24/2022 3:46 AM Hartmut Henkel <hartmut_henkel@gmx.de> wrote:
> 
>  
> Hi,
> 
> here seems to be some one-off error in gmpl/glpk (5.0, debian Linux):
> 
> param v := 131072;
> param n := 20; # number of bits
> set J  := 1..n; # set of all bits
> var x{j in J}, binary;
> var e, >= 0;
> minimize slack: e;
> 
> s.t. cs1: sum{j in J} (2**(j - 1) * x[j]) - v <=  e;
> s.t. cs2: sum{j in J} (2**(j - 1) * x[j]) - v >= -e;
> 
> solve;
> 
> printf "v: %d\nv: ", v;
> for {j in J} printf "%d", x[n - j + 1];
> printf "\n";
> printf "v: %d\n", sum{j in J} (2**(j - 1) * x[j]);
> printf "e: %d\n", e;
> 
> end;
> 
> Here it prints:
> 
> v: 131072
> v: 0011111111111111111
> v: 131071
> e: 0
> 
> With v = 131071 or v = 131073 or v = 65536 it works fine. Also fine with
> larger numbers like v = 888888. Same problem when solving the exported
> .lp file, which looks ok., confirmed by another solver. Seems not to be
> a general int limitation or printing issue. Do you have any idea what's
> happening here?
> 
> Best Regards, Hartmut