This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/4943] Inconsistent rounding behaviour for sprintf and IEEE doubles


------- Additional Comments From vincent+libc at vinc17 dot org  2007-10-04 00:47 -------
(In reply to comment #43)
> Correct.  However, since my conversion understands that a maximum of 15
> significant digits is implicit in IEEE doubles,

A double is represented in binary and has 53 significant digits (bits) in base
2. Speaking of significant digits in base 10 for a binary number doesn't make
much sense, as there isn't a canonical definition. For instance, if you want to
make sure to distinguish any two double-precision numbers after a conversion
into base 10, you need 17 decimal digits (BTW, this is explicitly stated in the
IEEE-754 standard -- check it if you don't believe me).

> Whilst I realise that some people would love to see as a decimal representation
> of the binary number,
>   printf("%.32f", 9.07443991390669);
> =>9.07443991390669069119212508667260
> 
> ...and are used to seeing this, all of the extra digits after significant digit
> 15 are misleading.  They really do not make any sense in the decimal context.

The number is represented in binary, but it is after all a real number. As a
real number, it can make sense to display it with whatever number of digits. For
instance, if one computes 2^100, the number is an exact power of 2, so that
outputting all its digits is decimal is completely meaningful.

> People seem to think that the decimal digits after significant digit somehow
> contribute to the precision of the value, and are meaningful, where in fact
> they are not meaningful in the decimal world, since the binary number cannot
> be represented accurately as decimal beyond a precision of 15.

You haven't understood the difference between "precision" and "accuracy". See
the example above. Though 2^100 is represented in a double with a 53-bit
*precision*, its *accuracy* is infinite (since the exact value is represented).

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4943

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]