[multiprecision] Bug in double to cpp_bin_float conversion?
Consider the following code: #include <boost/multiprecision/cpp_bin_float.hpp> #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<float128_t>::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
Rob Conde wrote:
Consider the following code:
#include <boost/multiprecision/cpp_bin_float.hpp> #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<float128_t>::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?
What behavior do you expect?
On 13 Apr 2016, at 23:32, Rob Conde <rob.conde@ai-solutions.com> wrote:
Consider the following code:
#include <boost/multiprecision/cpp_bin_float.hpp> #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<float128_t>::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>
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 <boost-bounces@lists.boost.org> on behalf of M.A. van den Berg <thijs@sitmo.com> 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 <rob.conde@ai-solutions.com> wrote:
Consider the following code:
#include <boost/multiprecision/cpp_bin_float.hpp> #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<float128_t>::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
participants (3)
-
M.A. van den Berg -
Peter Dimov -
Rob Conde