Re: [boost] [Interval] Bug when constructing from anunsigned integer type

From: John Maddock (john_at_[hidden])
Date: 2008-01-03 12:47:38

Guillaume Melquiond wrote:
> Le mercredi 26 décembre 2007 à 13:02 +0000, John Maddock a écrit :
>> This compiles:
>>
>> boost::interval<double> in(1u);
>>
>> but creates a nonsense interval.
>>
>> IMO this should work?
>
> It works fine for me. Which testcase and which compiler are causing
> trouble?

I've since found the issue to be specific to rounded_arith_opp: it negates 
the value being converted even if it's an unsigned type.  The attached patch 
fixes this, and also suppresses some pesky MSVC warnings.

You can see the full set of patches I've been working on here: 
http://svn.boost.org/trac/boost/changeset/42438

Along with some more std lib functions and other goodies here: 
http://svn.boost.org/trac/boost/browser/sandbox/interval_math_toolkit/boost/math/bindings/interval.hpp

The floor/ceil functions are the problematic ones here, these should 
probably throw in the case that the two bounds don't yield the same result 
:-)

The most important addition is for pow: which requires modifying the 
transcendental function traits class support.

I also found it very useful to have a traits class that always returned 
nearest rounded results for the transcendental functions when doing 
"approximate" interval arithmetic:

* Using rounded_transc_opp led to situations where the resulting interval 
was invalid (rounding down returned a larger value than rounding up) with 
msvc and std::exp.  I would expect to see the same with rounded_transc_std.
* Using rounded_transc_exact as a "dummy" class with rounded_arith_opp 
produced quite erroneous results with std::exp, I gave up testing it after 
that.  I assume it could be used in conjunction with rounded_transc_std OK, 
but then normal arithmetic would be slower?

So providing a traits class that resets the rounding mode to nearest before 
making a std lib call seemed sensible, on the assumption that these calls 
occur much less frequently than normal arithmetic, and that the cost of the 
call will swamp the cost of the rounding mode change anyway.  I haven't 
investigated using a correctly rounded solution yet, but that will come :-)

Let me know if you want any more information about these patches.  I'm not 
sure how these fit with the revised std lib design though?

Regards, John.