Re: [Boost-users] [numeric conversation] behavior on std::numeric_limits<double>::max() + eps with numeric_cast

Subject: Re: [Boost-users] [numeric conversation] behavior on std::numeric_limits<double>::max() + eps with numeric_cast
From: Olaf Peter (ope-devel_at_[hidden])
Date: 2014-06-11 07:06:38

Am 10.06.2014 18:28, schrieb Brandon Kohn:
> On 6/9/2014 14:13 PM, Olaf Peter wrote:
>> attached my 'playground', it's basically the UDT example simplified
>> extended with math_round capabilities. The range_checker also checks on
>> finite values, but I'm not sure if this is really required (I would say
>> yes, since operator[<,>} wouldn't work on NaN or Inf). Line 486 doesn't
>> compile - vice versa doesn't work for some reasons.
>
> A couple of points:
>
> 1) the range checker you've implemented expects that value is always of
> type core::intrinsic_type<T> as it calls value.to_builtin(); This fails
> when the 'Source' type/argument_type is a different type (like int.)
>
> 2) On the other hand, when Target is of type core::intrinsic_type<T> and
> Source is a fundamental type, certain comparison operations fail because
> the fundamental type doesn't know how to compare with
> core::intrinsic_type<T>.
>
> In order to get this compiling I had to split the range checker into two
> specializations like so:
>
> //! Define a custom range checker
> template<typename Traits, typename OverFlowHandler>
> struct range_checker;
>
> //! One for checking intrinsic_type against some other type (fundamental)
> template<typename T, typename SourceT, typename OverFlowHandler>
> struct range_checker
> <
>      boost::numeric::conversion_traits<core::intrinsic_type<T>, SourceT>
>    , OverFlowHandler
>> ;
>
> //! And another one for checking other types against intrinsic_type
> template<typename T, typename TargetT, typename OverFlowHandler>
> struct range_checker
> <
>      boost::numeric::conversion_traits<TargetT, core::intrinsic_type<T>>
>    , OverFlowHandler
>> ;

thank you for pointing this out.

> I should note that in each of these specializations care must be taken
> that bounds are properly checked given the context of the conversion
> direction. In my test I essentially converted the fundamental type to an
> instance of intrinsic_type (via the template constructor) and then used
> that to compare with the bounds of the intrinsic_type<T>. In a real
> world example this is possibly nonsense.

I thought this is what the checker does already, including test on NaN 
and Inf. Could you explain this?

Thank you,
Olaf