Thanks for that explanation - I was aware of the details but the outcome surprised me...I wasn't fully thinking it through. Indeed I confirmed the same behavior converting from float to double. Thanks for your time, Rob ________________________________________ From: Boost on behalf of M.A. van den Berg Sent: Wednesday, April 13, 2016 5:52 PM To: boost@lists.boost.org Subject: Re: [boost] [multiprecision] Bug in double to cpp_bin_float conversion?

On 13 Apr 2016, at 23:32, Rob Conde wrote:

Consider the following code:

#include #include <iostream>

int main() { typedef boost::multiprecision::cpp_bin_float_quad float128_t;

float128_t f1(1e-9);

float128_t f2("1e-9");

std::cout << std::setprecision(std::numeric_limits::max_digits10);

std::cout << f1 << std::endl; std::cout << f2 << std::endl;

return 0; }

I'm getting as output:

1.000000000000000062281591457779856419e-09 9.999999999999999999999999999999999325e-10

The conversion of the double literal is not as expected.

On wand box: http://melpon.org/wandbox/permlink/uSGNQZAEEytmb3ao

Is this a bug? If not, what would be the correct way to get my expected behavior?

Thanks,

Rob Conde

This has to do with finite resolution of doubles, a double has roughly 16 significant, e.g. these next 3 numbers will all be converted to the same double (if truncated the last digits because it cant hold it) 0.99999999999999999-09 1.00000000000000000-09 1.00000000000000001-09 If you map a low resolution double to a higher resolution mil number then it’s just going to pad extra zeros at the end. The number you see might look weird, but in binary float notation it ends in a nice list of zeros. http://www.binaryconvert.com/result_double.html?decimal=049101045057 http://www.binaryconvert.com/result_double.html?decimal=049101045057 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost