[Coin-discuss] OsiCpx optimality for MIPs
Jonathan Eckstein
jeckstei at rutcor.rutgers.edu
Fri Jan 28 15:21:36 EST 2005
0 is not a good tolerance, but .01% (4 digits) is a surprisingly loose
tolerance! I think such a tolerance could cut most of the tree out of
some of the old MIPLIB 3 problems. If the absolute tolerance can
override the relative one even if both the gap and incumbent are
non-zero, that is also surprising.
Generally, I think the default MIP tolerance should be in the same
ballpark as the LP tolerance. Setting a MIP tolerance smaller than the
LP tolerance isn't advisable.
-- Jonathan
Matthew Saltzman wrote:
> On Fri, 28 Jan 2005, Brady Hunsaker wrote:
>
>> I just ran into a quirk with OsiCpx solving a MIP. CPLEX 9.0 has
>> default gap parameters so that it stops the branch-and-bound process
>> if the gap gets within 0.01% or an absolute value of 0.000001.
>>
>> This caused the solution process to stop, but
>> OsiCpx->isProvenOptimal() returned false, because CPLEX returns a
>> separate return code (CPXMIP_OPTIMAL_TOL) for this situation.
>>
>> I believe this should be corrected. I can see two possible solutions:
>> 1. Reply true to isProvenOptimal() if CPXMIP_OPTIMAL_TOL is returned,
>> even though this is technically incorrect.
>> 2. Explicitly set the gap parameters to 0 in branchAndBound().
>>
>> I'm using the first solution right now, but I'd like to hear any other
>> opinions, especially from OsiCpx maintainers.
>>
>> Brady
>
>
> My first reaction is in favor of solution 1.
>
> (1) Overriding tolerances that users may have reason to set is a bad idea.
>
> (2) Most users probably would accept that a solution that's within
> tolerance is optimal "for all practical purposes". If a user wants a
> guarantee of optimality, he can set CPXMIP_OPTIMAL_TOL to zero himself.
>
> Is this a small enough example to pass around for testing? I wonder how
> other solver/SI combinations handle this issue.
>
More information about the Coin-discuss
mailing list