Re: One-off error in the MIP solver?
Antti Lehtila <[email protected]> Mon, 24 Jan 2022 20:26:24 +0200
| Newsgroups | gmane.comp.gnu.glpk |
|---|---|
| Organization | VTT |
| Message-ID | <[email protected]> |
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Hartmut,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Please find below my attempt to explain
what's happening there. <br>
</div>
<div class="moz-cite-prefix">I think the integrality tolerance is
parm->tol_int = 1e-5; (hard-coded), at least it was so a few
years ago.<br>
</div>
<div class="moz-cite-prefix">And indeed, the solution for the LP
relaxation already happens to satisfy the tolerances. The LP
solution is as follows:<br>
</div>
<div class="moz-cite-prefix">------------------------<br>
</div>
<div class="moz-cite-prefix"><font face="monospace"> No. Row
name St Activity Lower bound Upper bound Marginal<br>
------ ------------ -- ------------- ------------- -------------
-------------<br>
1 slack B 0
<br>
2 cs1 NU 131072
131072 < eps<br>
3 cs2 B 131072 131072
<br>
<br>
No. Column name St Activity Lower bound Upper
bound Marginal<br>
------ ------------ -- ------------- ------------- -------------
-------------<br>
1 x[1] NU 1 0
1 < eps<br>
2 x[2] NU 1 0
1 < eps<br>
3 x[3] NU 1 0
1 < eps<br>
4 x[4] NU 1 0
1 < eps<br>
5 x[5] NU 1 0
1 < eps<br>
6 x[6] NU 1 0
1 < eps<br>
7 x[7] NU 1 0
1 < eps<br>
8 x[8] NU 1 0
1 < eps<br>
9 x[9] NU 1 0
1 < eps<br>
10 x[10] NU 1 0
1 < eps<br>
11 x[11] NU 1 0
1 < eps<br>
12 x[12] NU 1 0
1 < eps<br>
13 x[13] NU 1 0
1 < eps<br>
14 x[14] NU 1 0
1 < eps<br>
15 x[15] NU 1 0
1 < eps<br>
16 x[16] NU 1 0
1 < eps<br>
17 x[17] NU 1 0
1 < eps<br>
18 x[18] B 7.62939e-06 0 1
<br>
19 x[19] NL 0 0
1 < eps<br>
20 x[20] NL 0 0
1 < eps<br>
21 e NL 0
0 1 <br>
</font>------------------------</div>
<div class="moz-cite-prefix">As you can see, the variable x[18] is
basic at the value of 7.63e-6, which nicely satisfies the
integrality tolerance. The Karush-Kuhn-Tucker conditions also all
have high quality in the LP relaxation solution. So, it appears
that when entering the MIP algorithm, this initial LP solution is
immediately accepted as the optimal MIP solution. But then, it
seems that Glpk rounds off the levels of the binary variables, and
as a result, in the final solution x[18] has zero value and the
second constraint is actually shown violated. Indeed, the MIP
solution is listed showing the constraint violation and low
quality for KKT.PB, as follows:<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><font face="monospace"> No. Row
name Activity Lower bound Upper bound<br>
------ ------------ ------------- ------------- -------------<br>
1 slack 0
<br>
2 cs1 131071 131072
<br>
3 cs2 131071 131072
<br>
<br>
No. Column name Activity Lower bound Upper bound<br>
------ ------------ ------------- ------------- -------------<br>
1 x[1] * 1 0 1
<br>
2 x[2] * 1 0 1
<br>
3 x[3] * 1 0 1
<br>
4 x[4] * 1 0 1
<br>
5 x[5] * 1 0 1
<br>
6 x[6] * 1 0 1
<br>
7 x[7] * 1 0 1
<br>
8 x[8] * 1 0 1
<br>
9 x[9] * 1 0 1
<br>
10 x[10] * 1 0 1
<br>
11 x[11] * 1 0 1
<br>
12 x[12] * 1 0 1
<br>
13 x[13] * 1 0 1
<br>
14 x[14] * 1 0 1
<br>
15 x[15] * 1 0 1
<br>
16 x[16] * 1 0 1
<br>
17 x[17] * 1 0 1
<br>
18 x[18] * 0 0 1
<br>
19 x[19] * 0 0 1
<br>
20 x[20] * 0 0 1
<br>
21 e 0 0
<br>
<br>
Integer feasibility conditions:<br>
<br>
KKT.PE: max.abs.err = 0.00e+00 on row 0<br>
max.rel.err = 0.00e+00 on row 0<br>
High quality<br>
<br>
KKT.PB: max.abs.err = 1.00e+00 on row 3<br>
max.rel.err = 7.63e-06 on row 3<br>
Low quality<br>
</font><br>
<hr width="100%" size="2"></div>
<br>
<div class="moz-cite-prefix">On 24.01.2022 11:46, Hartmut Henkel
wrote:<br>
</div>
<blockquote type="cite" cite="mid:[email protected]">
<pre class="moz-quote-pre" wrap="">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
.
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>