Quantcast
Channel: Yet Another Math Programming Consultant
Viewing all articles
Browse latest Browse all 809

MIP Gap Artifacts

$
0
0
For large integer programming models we may not be always willing to wait for a global, proven optimal solution. A straightforward way to deal with this is to set a time limit. A different way is to set a gap tolerance on the gap between the best possible and the best found integer solution. A typical gap tolerance is a few percent. Integer solvers display the gap prominently in the log. In most cases we talk about a relative gap. There is also an absolute gap with a corresponding absolute gap tolerance. In the following I talk about the relative gap.

It may come as a surprise, but the MIP gap can increase. From a Cplex log:


        Nodes                                         Cuts/
Node Left Objective IInf Best Integer Best Bound ItCnt Gap

*
0+ 0300.0000 -120.0000140.00%
Found incumbent of value
300.000000 after 0.09 sec. (5.80 ticks)
00 -120.0000153300.0000 -120.0000229140.00%
00 -120.0000163300.0000Cuts: 118356140.00%
00 -120.0000129300.0000Cuts: 64427140.00%
00 -120.0000142300.0000Cuts: 180503140.00%
*
0+ 0 -10.0000 -120.0000 ---
Found incumbent of value -
10.000000 after 0.31 sec. (67.99 ticks)
02 -120.0000128 -10.0000 -120.0000503 ---
Elapsed time =
0.33 sec. (71.72 ticks, tree = 0.01 MB, solutions = 2)
414350 -120.0000155 -10.0000 -120.00008074 ---
Cuts: 60
*
500+ 375 -30.0000 -120.0000300.00%
Cuts: 4
Found incumbent of value -
30.000000 after 1.44 sec. (418.43 ticks)
500377 -110.0000148 -30.0000 -120.00009855300.00%
610483 -120.0000157 -30.0000 -120.000012092300.00%
632376 -120.0000176 -30.0000 -120.000012662300.00%
710268 -110.0000166 -30.0000 -120.000013622300.00%
950360 -73.0094112 -30.0000 -120.000016832300.00%
Cuts: 216
1110430 -89.6733148 -30.0000 -120.000019495300.00%
1398650 -91.0030118 -30.0000 -120.000025098300.00%
Cuts: 72
1759958 -43.276895 -30.0000 -120.000031198300.00%
30312036 -60.174097 -30.0000 -119.226249706297.42%
Elapsed time =
13.67 sec. (4413.94 ticks, tree = 0.73 MB, solutions = 3)
47213471 -77.9342132 -30.0000 -116.654271843288.85%
Cuts: 42
58674399 -82.3794152 -30.0000 -115.291389434284.30%
Cuts: 8
72765520 -95.5742137 -30.0000 -113.0523107572276.84%
Cuts: 20
87296670 -68.9411119 -30.0000 -110.8877127085269.63%
Cuts: 28
99197614 -40.000086 -30.0000 -110.0000145286266.67%

The reason is the Best Integer bound changed sign.

GAP definitions


The Cplex definition of the relative gap is [1]:
\[\mathit{RelGap} = \frac{|\mathit{BestBound}-\mathit{BestInteger}|}{10^{-10}+ |\mathit{BestInteger}|} \]


This means the following scenario is possible:


Although he absolute gap (the difference between the grey and the orange line) is decreasing monotonically, the relative gap (the yellow line) is not. Note that the gap relates to the scale on the right (with percentages).

Often the BestBound and the BestInteger quantities are called the Lower and Upper Bound. (Note: this makes sense when minimizing. If maximizing we need to flip these.) So we can write the Cplex relative gap as (approximately):
\[ \mathit{RelGap} = \frac{|U-L|}{ |U|} \]

Most solvers use a similar relative gap. Some solvers such as Baron [2] use a slightly different definition:
\[ \mathit{RelGap} = \frac{|U-L|}{ |L|} \]

This can make a difference. When using bounds in the picture, the Baron relative gap would look like:


In this case the Baron relative gaps are better than the ones for Cplex. This is not always the case. Below is a Baron log:


  Iteration    Open nodes         Time (s)    Lower bound      Upper bound
* 114.000.0000010.0000
114.000.376100E-0110.0000
12+ 634.002.5000010.0000
19+ 1165.002.5587510.0000
29+ 1495.002.5587510.0000
40+ 18125.002.5587510.0000
51+ 19156.002.5606710.0000
59+ 17186.002.7324910.0000
70+ 17217.003.3272010.0000
81+ 14247.004.1082610.0000
88+ 14277.005.0000010.0000
100+ 10308.005.1529010.0000
111+ 6338.005.5145410.0000
123+ 4368.005.9831610.0000
1290382.009.0909110.0000


If we calculate both relative gaps for these bounds we see:



Here the Baron gap is more difficult.

GAMS suggests an even more crazy formula [3]:
\[ \mathit{RelGap} = \frac{|U-L|}{\max( |U|,|L|)} \]


Finally returning to our first Cplex log. We see very large gaps. If you are embarrassed about these large gaps, you can easily reformulate the objective. After using \[\min\> z = 1000 + z_{\text{orig}}\] we see:


        Nodes                                         Cuts/
Node Left Objective IInf Best Integer Best Bound ItCnt Gap

* 0+ 01300.0000880.000032.31%
Found incumbent of value 1300.000000 after 0.08 sec. (5.85 ticks)
00880.00001531300.0000880.000022932.31%
00880.00001631300.0000Cuts: 11835632.31%
00880.00001291300.0000Cuts: 6442732.31%
00880.00001421300.0000Cuts: 18050332.31%
* 0+ 0990.0000880.000011.11%
Found incumbent of value 990.000000 after 0.41 sec. (68.34 ticks)
02880.0000128990.0000880.000050311.11%
Elapsed time = 0.80 sec. (72.31 ticks, tree = 0.01 MB, solutions = 2)
25792059923.853399990.0000880.00003189111.11%
Cuts: 78
* 2581+ 1437980.0000880.000010.20%
Found incumbent of value 980.000000 after 2.05 sec. (311.11 ticks)

So just looking at the relative gap in isolation is not that useful: we can always fudge it.

References



  1. Cplex Relative MIP gap tolerance, https://www.ibm.com/support/knowledgecenter/SSSA5P_12.8.0/ilog.odms.cplex.help/CPLEX/Parameters/topics/EpGap.html
  2. Baron Manual, http://www.minlp.com/downloads/docs/baron%20manual.pdf
  3. What is optca/optcr? https://support.gams.com/solver:what_is_optca_optcr

Viewing all articles
Browse latest Browse all 809

Trending Articles