Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk