<html><body>
<p>Torsten,<br>
<br>
I have found the problem. Before Cbc 2.2 probing was done on all rows. Then it was decided that it was best to leave out dense rows to try and improve the speed of probing. However my brain was not working very well as I forgot that if we have a solution, then the objective row is added as a constraint. Very often this constraint will be dense - so in some cases it was being added and then thrown out again. This is what made the difference as in some cases heuristics were getting good solutions.<br>
<br>
I have made some changes in trunk, but need to test them a bit more before they go in stable. As I am one of the few people with limited access to broadband (during part of the year) and for various other reasons, I may not be able to update stable for a few days. If you are using stable/2.3 you could change lines 4149,4150 of CbcSolver.cpp to 10000. As the quality of the solutions from the heuristics vary a lot on the problem you sent me, the objective after cuts varies. Playing around with 2.3 I did get 246.295 on one run.<br>
<br>
John<br>
<br>
<br>
<img width="16" height="16" src="cid:1__=0ABBFCB2DFC617158f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for "Torsten Fahle" ---08/27/2009 01:00:40 PM---Haroldo, > Did you get the integer optimal solution with "><font color="#424282">"Torsten Fahle" ---08/27/2009 01:00:40 PM---Haroldo, > Did you get the integer optimal solution with all versions ?</font><br>
<br>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFCB2DFC617158f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">From:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFCB2DFC617158f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">"Torsten Fahle" <Torsten.Fahle@inform-ac.com></font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFCB2DFC617158f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">To:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFCB2DFC617158f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2"><cbc@list.coin-or.org></font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFCB2DFC617158f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">Date:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFCB2DFC617158f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">08/27/2009 01:00 PM</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFCB2DFC617158f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">Subject:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFCB2DFC617158f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">[Cbc] Antw: Re: Cut efficiency in cbcSolve for versions 2.0.0, 2.1.0, 2.2.2and 2.3.0</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFCB2DFC617158f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">Sent by:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFCB2DFC617158f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">cbc-bounces@list.coin-or.org</font></td></tr>
</table>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt>Haroldo,<br>
<br>
> Did you get the integer optimal solution with all versions ?<br>
> I'm just thinking that perhaps the better bounds of previous versions could<br>
> include inequalities which could cut integer optimal solutions - these<br>
> issues perhaps are fixed in newest releases....<br>
<br>
This could be the case. However, solution values found by <br>
* CBC 2.0.0 with probing on and no other cuts (246.295513999) <br>
* CBC 2.3.0 without any cuts (246.2995200001)<br>
differ only slightly by less than 1e-5. This is probably in the area of internal epsilons<br>
in the code, so it's hard to say from the outside whether some cuts removed an optimal solution<br>
in the older code.<br>
By the way: CPLEX 9 claims that 246.299514 is optimal, XPRESS 2008 stops at 246.299524.<br>
Thus, it's hard to say which result is really better and which one is due to numerical issues.<br>
<br>
Torsten<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Cbc mailing list<br>
Cbc@list.coin-or.org<br>
</tt><tt><a href="http://list.coin-or.org/mailman/listinfo/cbc">http://list.coin-or.org/mailman/listinfo/cbc</a></tt><tt><br>
</tt><br>
<br>
</body></html>