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 struct range_checker; //! One for checking intrinsic_type against some other type (fundamental) template struct range_checker < boost::numeric::conversion_traits , OverFlowHandler

;

//! And another one for checking other types against intrinsic_type template struct range_checker < boost::numeric::conversion_traits , OverFlowHandler

;

In each of these specializations I wrote logic specific to the conversion direction. I also had to add the unary minus operator to core::instrinsic_type. I've attached the file I modified for my tests (which were done in visual studio 2008.) 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.

Is there a way to get a stack trace using boost to find the code part which triggers the exception in the source? I mean here it would be e.g. line 478 if x would be greater MAX_INT.

I would just use whatever debugger you have handy.

Is it usefull to add boost exception infos about the calling args in overflow_handler? Is there a clever way since the overflow_handler isn't templated so I have no info about the type and value to be converted.

Where is the error for the vise versa cast at line 486?

The overflow handler was designed to communicate positive and negative overflow. It assumes the range checker is working properly for all inputs. So I think the the best way to develop these is to simply write tests for all the types of inputs you expect your range_checker to see and make sure it gives you the correct outputs. (i.e. I would test these directly on the range_checker::out_of_range interface.) Hope this helps, Brandon

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. Cheers, Brandon

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'

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

On 6/15/2014 14:15 PM, Olaf Peter wrote:

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'

If you define BOOST_NUMERIC_CONVERSION_RELAX_BUILT_IN_CAST_TRAITS then you can define the conversions for fundamental types. Even so, converting from double to double won't affect the value. There is a layer that checks for this an implements a trivial conversion that does nothing but return a const T&. On 6/15/2014 14:56 PM, Olaf Peter wrote:

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.

What type of round does RoundMath do?

so, I can't use it like boost.math.round () with polycies or doubles, isn't it? I don't think it (numeric_cast) should be used to round doubles. For

On 6/16/2014 09:27 AM, Olaf Peter wrote: that I would just call your rounder directly. I wouldn't recommend this, but if you really wanted to use numeric_cast due to other reasons, you could try specializing it for the double to double case: namespace boost { template <> double numeric_cast(double value) { return boost::math::round(value); } } Cheers, Brandon

...

...

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'

If you define BOOST_NUMERIC_CONVERSION_RELAX_BUILT_IN_CAST_TRAITS then you can define the conversions for fundamental types. Even so, converting from double to double won't affect the value. There is a layer that checks for this an implements a trivial conversion that does nothing but return a const T&.

so, I can't use it like boost.math.round () with polycies or doubles, isn't it?

Why would you want to? It's a type conversion utility not a rounding one, if you want to do rounding why not use the Boost.Math functions directly? John.

Am 09.06.2014 14:33, schrieb Antony Polukhin:

Hello,

at this time I play with numeric_cast and struggle with this:

first: double z = std::numeric_limits<double>::max(); z += 2*std::numeric_limits<double>::epsilon(); // doesn't matter if 1*eps std::cout << z << std::endl; std::cout << boost::numeric_cast<double>(z) << '\n';

I would expect that an exception is thrown which isn't, the output is 1.79769e+308 1.79769e+308

Machine epsilon gives an upper bound on the relative error due to rounding in floating point arithmetic. In other words absolute error for max value would be:

double non_rel = std::numeric_limits<double>::max() * std::numeric_limits<double>::epsilon();

2*std::numeric_limits<double>::epsilon() is much less than non_rel and adding it won't cause overflow: number will be rounded to std::numeric_limits<double>::max()

thanks for answer, but eps = 2.22045e-16 max*eps = 3.99168e+292 on my machine, no_rel is a high value ... Is this right?, I thought eps is the absolute error/uncertainly of representation in real values. But probably I have to read about FP ... Thanks, Olaf