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