Re: [boost] [math] potentian bug: iround throws, given double( numeric_limits<int>::min() )

Subject: Re: [boost] [math] potentian bug: iround throws, given double( numeric_limits<int>::min() )
From: Krzysztof Czainski (1czajnik_at_[hidden])
Date: 2011-10-24 09:14:35

[Krzysztof Czaiński]

> Would you like a ticket for the following round_to as well?
>> template < class T >
>> T round_to( const T& x, const T& order )
>> {
>> return round( x / order ) * order;
>> }
>>
>
> [John Maddock]

> I'm not sure about that one, if "order" is anything other than a power of
> T's radix then the result will be rounded - ie the result will not
> necessarily actually be a true multiple of "order"?

Do you mean the loss of precision when doing "x/order" and then
"<result>*order" ? Anyway, I am not really convinced myself whether this
round_to() is a good candidate for adding to boost ;-) I just wasn't sure if
you were asking for a ticket with that as well.

However, my aside question remains, can that be implemented better?

[Krzysztof Czaiński]

>  I'm still not sure if: can r > boost::integer_traits<R>::**const_max be
>> true,
>> and still static_cast<R>(r) == boost::integer_traits<R>::**const_max?
>>
>
> [John Maddock]

> Good question, I believe that can be the case if *r has not been rounded*,
> for example if r == boost::integer_traits<R>::**const_max + 0.1.
>

What I meant above, and should have written, is that "T r = round(x)", where
x is the input value of a floating-point type T. With this assumption, do
the conditions still hold, or can there be some roundidg error messing with
them?

Regards
Kris