Re: [boost] boost interval arithmetic

Subject: Re: [boost] boost interval arithmetic
From: Павел Кудан (coodan_at_[hidden])
Date: 2015-01-15 06:22:25

>But it *can* return a single interval. Always. And that's the correct
>result given the definition being used: a single interval that encapsulated
>the value. You are looking for a different definition, one of many possible
>definitions.

But, please, tell are you agree that

[-inf, inf] 
IS NOT 
[-inf, -1] U [1, inf]

The hull of intervals (mentioned in documentation in some misleading way as a return value) is not intervals itself.
In other case you must confess that 2 + 2 == [-inf, inf], as it is similar statement with [-inf, inf] == [-inf, -1] U [1, inf]

>Comparison is different, you can't always return True or False when there
>is partial overlap of intervals.
>You can however have various comparison definitions that *do* result in
>always True or False, e.g. the comparison "guaranteed to be be
>*always* smaller".
The problem is than there is no difference with comparison. Comparison throws exception in intermediate situation (operator not applicable due to intervals overlaping, certain comparison not possible).
And arithmetic functions must also throw exception in intermediate situation (operator or function is not applicable due to not single interval result).

By the way, you just touched another behaviour properties of comparison operators of boost interval class - 'certain' and 'possible' comparison modes. Not sure that 'possible' mode adds some functionality, but definitely, its hard to locate error of comparison operator if comparison operator behaviour depends on namespace used :)

But at any comparison mode arithmetic functions must return correct result. 'Certain' result, if you like, using term of boost comparison operators descriptor. Or throw exception, as comparison operators do.