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

["paul at inet dot co dot za" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From paul at inet dot co dot za  2007-09-19 17:48 -------
(In reply to comment #1)
> I don't think there is a bug. The IEEE-754 standard doesn't seem to specify to
> which decimal value a halfway case should be rounded. As for consistency, the C
> function round() requires halfway cases to be rounded away from zero, but the
> IEEE-754 binary rounding rules require halfway cases to be rounded to an even
> mantissa.

I believe it is easy to miss the wood for the trees here.  

When one speaks of "rounding", we simply refer to the rule which decides how we
should promote one level of precision (eg. 25.5) to the next (26).  

The IEEE floating point arithmetic processor is programmable to allow a choice
in the rules one prefers depending on circumstance.  In this specific
circumstance, the formatting of a number for display, I would expect the
promotion of the value 25.5 to 26, rather than 25, which is indeed the result in
99% of the cases.  printf("%.0f", floor(25.5)) should give me the value 25,
whilst printf("%.0f", ceil(25.5)) should give the value 26.

By specifying a precision of 2 decimal places to the printf() function, for the
value 2597.625 (stored precisely to 3 decimals of precision) should logically be
promoted to the value 2597.63, and not 2597.62.  This in fact is the case for
the Microsoft C library, MSVCRT.DLL.

Whether or not you choose to describe this as "unexpected behaviour" or less
diplomatically, as a "bug", the behaviour is certainly inconsistent, as shown in
the example.

-- 


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.