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-15 14:56:56

Am 15.06.2014 20:15, schrieb Olaf Peter:
> Am 11.06.2014 14:51, schrieb Brandon Kohn:
>>
>> On 6/11/2014 07:06 AM, Olaf Peter wrote:
>>> Am 10.06.2014 18:28, schrieb Brandon Kohn:
>>>> 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?
>>>
>> What I mean is that the range checker is checking the whether the values
>> in the source instance can be represented in the target instance. So one
>> must ensure that for a given conversion (like my_type -> int) a
>> range_checker type exists which can perform that check. Your original
>> checker did cover the types of checks needed, it just neglected to deal
>> with the interfaces on the respective types (source/target.) Apologies
>> if I'm stating the obvious.
>>
>> Let me know if you have any more issues. I'm happy to help.
> Thank you!
>
> Is there a way to override the default implementation for e.g. double? 
> The attached example fails to compile due to
> redefinition of 'struct boost::numeric::numeric_cast_traits<double, 
> double>'
>
Probably I did though to complicated before; but even using 
make_converter_from doesn't compile :( Is the way correct and only my 
typedef wrong?

BTW; why isn't there a RoundMath<> here, RoundEven<> policy does exist.

Thanks,
Olaf