
Boost : 
Subject: Re: [boost] boost interval arithmetic
From: ÐŸÐ°Ð²ÐµÐ» ÐšÑƒÐ´Ð°Ð½ (coodan_at_[hidden])
Date: 20150114 15:00:41
>
>> Simple example.
>>
>> Say, we are trying to estimate some physical value with interval
>> calculation depending on some measured values (as values are measured,
>> they are not exact, known to us as some ranges of possible values, it's
>> quite natural to use interval calculations here).
>>
>> Let it be some mass.
>>
>> A = [1,2]
>> B = [1, 1]
>>
>> M = A / B
>>
>> Calculated result with boot interval is [infinity, 1].
>
>It gives [inf,+inf] for me. If you get something different, please file a
>bug report in https://svn.boost.org/trac/boost/ with a compilable example
>and as much information as you can so we can reproduce your result.
>
>> OK, but mass cannot be negative...
>>
>> Correct part of answer [1, infinity] which means that we have at leastÂ
>> estimation of minimum for calculated value is lost...
(thank you for warning, you were right  I did not see your answer)
You are wrong that time but where right last time (in the answer which I did not initially noticed), when give another answer ' Actually, [inf,1][1,+inf]'.
Now you can see on own and mine example how special is interval arithmetic. Float arithmetic experience almost absolete here. I calculated  and make mistake in one value and typo in another ( [2, infinity] instead of [1, infinity] ). You tried twice  and got complitely different results (one is correct, another not). Boost interval class must be perfectly behavioured to protect user from mistakes.
But problem not in values of bounds. The problem is that documented behaviour of boost interval / operator in that case will be to return [inf, 1] and silently kill [1, inf]. But it must throw exception in such case.
On the other hand, interval boost acting here fully according its documented concept. That behaviour is documented. But not correct. So it is not bug. It is misconception.
That is why I tried to find its maintainers here to disscuss...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk