[Coin-discuss] Re: Coin-discuss Digest, Vol 14, Issue 9

Miroslav Karamanov miroslav at andrew.cmu.edu
Sat Dec 17 14:47:38 EST 2005


Thank you, Laci!
By the way, shouldn't variable over_ub (mail loop, line 69) 
be called under_ub. It is a little confusing this way :)

Happy holidays,
Miroslav


coin-discuss-request at list.coin-or.org wrote:

> Message: 2
> Date: Fri, 16 Dec 2005 15:48:30 -0500 (EST)
> From: Laszlo Ladanyi <ladanyi at us.ibm.com>
> Subject: Re: [Coin-discuss] Re: How to deal with tolerance?
> To: Discussions about open source software for Operations Research
> 	<coin-discuss at list.coin-or.org>
> Message-ID:
> 	<Pine.A41.4.21.0512161547010.29324-100000 at oslpp.watson.ibm.com>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> You are right, Miroslaw, it's not handled gracefully.
> 
> Right now I'm busy with travel plans, but when I'm back (end of Dec) I'll take
> a closer look. Feel free to bug me to get it done...
> 
> --Laci
> 
> On Fri, 16 Dec 2005, Miroslav Karamanov wrote:
> 
> 
>>Thank you, John!
>>
>>This fixes the problem (at least for the instance I tested).
>>
>>Still, what bothers me is that BCP_lp_user::test_full() 
>>finds violated bounds but it returns just NULL, as it would 
>>do in case of integer infesible solution. As a result, BCP 
>>tries to branch and aborts (if no branching variables are 
>>found). Probably this test of bounds is not necessary. 
>>Otherwise, its outcome should be handled separately.
>>
>>Best,
>>Miroslav
>>
>>
>>
>>>Date: Fri, 16 Dec 2005 10:17:58 -0500
>>>From: John J Forrest <jjforre at us.ibm.com>
>>>Subject: Re: [Coin-discuss] How to deal with tolerance?
>>>To: Discussions about open source software for Operations Research
>>>	<coin-discuss at list.coin-or.org>
>>>Message-ID:
>>>	<OFCD701799.07B0113C-ON852570D9.0053B03D-852570D9.00540B5C at us.ibm.com>
>>>Content-Type: text/plain; charset="us-ascii"
>>>
>>>Miroslav,
>>>
>>>That seems a large discrepancy so I would guess the problem is badly 
>>>scaled.  Clp can return an answer which is optimal when scaled but not 
>>>when unscaled.  This can be tested in Clp but you can modify the default 
>>>action of OsiClpSolverInterface::resolve by using 
>>>OsiClpSolverInterface::setCleanupScaling(n)  (suggested value of n = 1).
>>>
>>>See if that helps
>>>
>>>John Forrest
>>>
>>>
>>>
>>>Miroslav Karamanov <miroslav at andrew.cmu.edu> 
>>>Sent by: coin-discuss-bounces at list.coin-or.org
>>>12/15/2005 06:38 PM
>>>Please respond to
>>>Discussions about open source software for Operations Research 
>>>
>>>
>>>To
>>>coin-discuss at list.coin-or.org
>>>cc
>>>
>>>Subject
>>>[Coin-discuss] How to deal with tolerance?
>>>
>>>
>>>
>>>I am using BCP + CLP and I came accross the following 
>>>problem: the solution returned by CLP was found out of 
>>>bounds by BCP (in particular, BCP_lp_user::test_full())
>>>
>>>Obviously, both solvers use different precision. test_full 
>>>uses BCP_IntegerTolerance (set to 1e-5 by me). Please advise 
>>>  what the best way to deal with this issue is.
>>>
>>>I had to increase BCP_IntegerTolerance to 1e-3 in order to 
>>>avoid this problem but this is not a good solution.
>>>Shouldn't the tolerance for integrality be different from 
>>>the tolerance for bounds?
>>>Or should they be relative to the magnitude of numbers?
>>>The problem occurs with large integers (like 4000.0011 with 
>>>u.b. 4000)
>>>Thank you.
>>>
>>>Miroslav
>>
>>_______________________________________________
>>Coin-discuss mailing list
>>Coin-discuss at list.coin-or.org
>>http://list.coin-or.org/mailman/listinfo/coin-discuss
>>
> 



More information about the Coin-discuss mailing list