[Cbc] OsiCbc isProvenOptimal?

[Jan-Willem Goossens]

John,

Thanks again.
The fix works, most of the time. However, for example when the user interrupts the solve with ctr-c, then status!=0 and the same problem occurs (optimal=true)
Why not always return modelPtr_->isProvenOptimal()?

There are many other OsiCbc functions that use the modelPtr_->solver(), when the modelPtr_ (CbcModel) offers these functions itself. Why not have OsiCbc call the modelPtr function in all these cases?

Jan-Willem



> On 22-sep.-2014, at 22:30, Jan-Willem Goossens <jhmgoossens at hotmail.com> wrote:
> 
> John,
> 
> Thank you for your help. I'll give it a go and let you know. 
> 
> Jan-Willem
> 
>> On 22 Sep 2014, at 11:54, John Forrest <john.forrest at fastercoin.com> wrote:
>> 
>> Jan-Willem,
>> 
>> It has been said before that OsiCbc is not as well tested (or flexible) as using Cbc directly.
>> 
>> I have modified code in stable and trunk - tell me if anything is wrong.
>> 
>> John Forrest
>> 
>>> On 18/09/14 22:07, Jan-Willem Goossens wrote:
>>> Hi,
>>> 
>>> I'm getting unexpected results from the call to osiCbc.isProvenOptimal():
>>> For problems for which the LP relaxation is feasible, but no MIP
>>> solution exists, the osiCbc.isProvenOptimal() returns TRUE (wrong,
>>> IMO), while osiCbc.getModelPtr()->isProvenOptimal() returns FALSE
>>> (correct).
>>> 
>>> The reason seems to be that OsiCbc isProvenOptimal is implemented as
>>> bool OsiCbcSolverInterface::isProvenOptimal() const
>>> {
>>>  return modelPtr_->solver()->isProvenOptimal();
>>> }
>>> and thus return "isProvenOptimal" of the (latest?) LP that was solved.
>>> 
>>> Is this by design?
>>> 
>>> Thanks in advance for your help.
>>> 
>>> Regards,
>>> 
>>> Jan-Willem
>>> _______________________________________________
>>> Cbc mailing list
>>> Cbc at list.coin-or.org
>>> http://list.coin-or.org/mailman/listinfo/cbc
>> 
>> _______________________________________________
>> Cbc mailing list
>> Cbc at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/cbc
>>