Double precision - decimal places

Question

From what I have read  a value of data type double has an approximate precision of 15 decimal places   However  when I use a number whose decimal representation repeats  such as 1 0 7 0  I find that the variable holds the value of 0 14285714285714285 - which is 17 places  via the debugger    I would like to know why it is represented as 17 places internally  and why a precision of 15 is always written at  15

User · Answer

IEEE 754 floating point is done in binary. There's no exact conversion from a given number of bits to a given number of decimal digits. 3 bits can hold values from 0 to 7, and 4 bits can hold values from 0 to 15. A value from 0 to 9 takes roughly 3.5 bits, but that's not exact either.

An IEEE 754 double precision number occupies 64 bits. Of this, 52 bits are dedicated to the significand (the rest is a sign bit and exponent). Since the significand is (usually) normalized, there's an implied 53^rd bit.

Now, given 53 bits and roughly 3.5 bits per digit, simple division gives us 15.1429 digits of precision. But remember, that 3.5 bits per decimal digit is only an approximation, not a perfectly accurate answer.

Many (most?) debuggers actually look at the contents of the entire register. On an x86, that's actually an 80-bit number. The x86 floating point unit will normally be adjusted to carry out calculations to 64-bit precision -- but internally, it actually uses a couple of "guard bits", which basically means internally it does the calculation with a few extra bits of precision so it can round the last one correctly. When the debugger looks at the whole register, it'll usually find at least one extra digit that's reasonably accurate -- though since that digit won't have any guard bits, it may not be rounded correctly.

User · Answer

In most contexts where double values are used  calculations will have a certain amount of uncertainty   The difference between 1 33333333333333300 and 1 33333333333333399 may be less than the amount of uncertainty that exists in the calculations   Displaying the value of  2 3   2 3  as  1 33333333333333  is apt to be more meaningful than displaying it as  1 33333333333333319   since the latter display implies a level of precision that doesn t really exist   In the debugger  however  it is important to uniquely indicate the value held by a variable  including essentially-meaningless bits of precision   It would be very confusing if a debugger displayed two variables as holding the value  1 333333333333333  when one of them actually held 1 33333333333333319 and the other held 1 33333333333333294  meaning that  while they looked the same  they weren t equal    The extra precision shown by the debugger isn t apt to represent a numerically-correct calculation result  but indicates how the code will interpret the values held by the variables

User · Answer

It is because it s being converted from a binary representation  Just because it has printed all those decimal digits doesn t mean it can represent all decimal values to that precision  Take  for example  this in Python    gt  gt  gt  0 14285714285714285 0 14285714285714285  gt  gt  gt  0 14285714285714286 0 14285714285714285   Notice how I changed the last digit  but it printed out the same number anyway

User · Answer

Decimal representation of floating point numbers is kind of strange  If you have a number with 15 decimal places and convert that to a double  then print it out with exactly 15 decimal places  you should get the same number  On the other hand  if you print out an arbitrary double with 15 decimal places and the convert it back to a double  you won t necessarily get the same value back   you need 17 decimal places for that  And neither 15 nor 17 decimal places are enough to accurately display the exact decimal equivalent of an arbitrary double  In general  you need over 100 decimal places to do that precisely   See the Wikipedia page for double-precision and this article on floating-point precision

User · Answer

A double holds 53 binary digits accurately  which is  15 9545898 decimal digits   The debugger can show as many digits as it pleases to be more accurate to the binary value   Or it might take fewer digits and binary  such as 0 1 takes 1 digit in base 10  but infinite in base 2   This is odd  so I ll show an extreme example   If we make a super simple floating point value that holds only 3 binary digits of accuracy  and no mantissa or sign  so range is 0-0 875   our options are   binary - decimal 000    - 0 000 001    - 0 125 010    - 0 250 011    - 0 375 100    - 0 500 101    - 0 625 110    - 0 750 111    - 0 875   But if you do the numbers  this format is only accurate to 0 903089987 decimal digits   Not even 1 digit is accurate   As is easy to see  since there s no value that begins with 0 4   nor 0 9    and yet to display the full accuracy  we require 3 decimal digits   tl dr   The debugger shows you the value of the floating point variable to some arbitrary precision  19 digits in your case   which doesn t necessarily correlate with the accuracy of the floating point format  17 digits in your case

User · Answer

An IEEE double has 53 significant bits  that s the value of DBL MANT DIG in  lt cfloat gt     That s approximately 15 95 decimal digits  log10 253    the implementation sets DBL DIG to 15  not 16  because it has to round down   So you have nearly an extra decimal digit of precision  beyond what s implied by DBL DIG  15  because of that   The nextafter   function computes the nearest representable number to a given number  it can be used to show just how precise a given number is   This program    include  lt cstdio gt   include  lt cfloat gt   include  lt cmath gt   int main         double x   1 0 7 0      printf  FLT RADIX    d n   FLT RADIX       printf  DBL DIG    d n   DBL DIG       printf  DBL MANT DIG    d n   DBL MANT DIG       printf    17g n  17g n  17g n   nextafter x  0 0   x  nextafter x  1 0        gives me this output on my system   FLT RADIX   2 DBL DIG   15 DBL MANT DIG   53 0 14285714285714282 0 14285714285714285 0 14285714285714288    You can replace   17g by  say    64g to see more digits  none of which are significant    As you can see  the last displayed decimal digit changes by 3 with each consecutive value   The fact that the last displayed digit of 1 0 7 0  5  happens to match the mathematical value is largely coincidental  it was a lucky guess   And the correct rounded digit is 6  not 5   Replacing 1 0 7 0 by 1 0 3 0 gives this output   FLT RADIX   2 DBL DIG   15 DBL MANT DIG   53 0 33333333333333326 0 33333333333333331 0 33333333333333337   which shows about 16 decimal digits of precision  as you d expect

User · Answer

It is actually 53 binary places  which translates to 15 stable decimal places  meaning that if you round a start out with a number with 15 decimal places  convert it to a double  and then round the double back to 15 decimal places you ll get the same number  To uniquely represent a double you need 17 decimal places  meaning that for every number with 17 decimal places  there s a unique closest double  which is why 17 places are showing up  but not all 17-decimal numbers map to different double values  like in the examples in the other answers

[c++] Double precision - decimal places

Examples related to c++

Examples related to c

Examples related to precision

Examples related to ieee-754