Boost C++ Libraries: Ticket #12327: cpp_rational::convert_to() does not return the nearest number

John Maddock — Thu, 14 Jul 2016 17:00:01 GMT

I believe it's an error in your test program, taking the first example:

0.099999999999999992 = 7205759403792793/72057594037927936
0.10000000000000001  = 3602879701896397/36028797018963968

Note that these fractions are exact (in the binary, not decimal sense).

Then r112 becomes 5404319552844595/54043195528445952 which is 0.0999999999999999962992565845828115319212277730305989583... in decimal, which rounds up to 0.10000000000000001 and not down to 0.099999999999999992 due to the "6" after the string of 9's.

komakisen@… — Fri, 15 Jul 2016 04:46:21 GMT

Replying to johnmaddock:

Then r112 becomes 5404319552844595/54043195528445952 which is 0.0999999999999999962992565845828115319212277730305989583... in decimal, which rounds up to 0.10000000000000001 and not down to 0.099999999999999992 due to the "6" after the string of 9's.

Thank you for investigating my program, but I still don't understand this point.

To begin with, 0.099999999999999992 is actually 0.09999999999999999167332... and 0.10000000000000001 is actually 0.1000000000000000055511... (they differ by 1ulp)

So 0.09999999999999999629925... is less than their midpoint 0.09999999999999999861222...

Also, double is a binary floating-point number. Thus I believe round-off calculation on a decimal digit "6" explains nothing here.

If I run the following program, I get 0.099999999999999992.

#include <iostream>
#include <iomanip>
using namespace std;
int main() {
   double d = 0.09999999999999999629926;
   std::cout << std::setprecision(17) << d << std::endl;
   return 0;
}

So isn't 0.099999999999999992 the expected result? Or am I confusing myself?

status, milestone changed; resolution set

John Maddock — Mon, 25 Jul 2016 18:17:56 GMT

status new → closed
resolution → fixed
milestone To Be Determined → Boost 1.62.0

You're correct, I was the one confused!

Fixed in https://github.com/boostorg/multiprecision/commit/7ebd9dfd9b0bc463642b065036a3cd6947a74431.

However, your second test case still fails testing rd12, in this case I *think* the bug is yours: r12 is

14411518807585589/144115188075855872

which in binary is exactly the 54 bit quantity:

0.000 1100110011 0011001100 1100110011 0011001100 1100110011 010 1
                                                    rounded here ^

And in this case no rounding up occurs since we have a tie and round to even.

Please do correct me and re-open if I'm wrong! :)

komakisen@… — Tue, 26 Jul 2016 14:41:34 GMT

Great work! Thank you very much! :)

And in this case no rounding up occurs since we have a tie and round to even.

Yes, you're right! Sorry for messing up.