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

["vincent+libc at vinc17 dot org" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From vincent+libc at vinc17 dot org  2007-09-21 15:13 -------
(In reply to comment #10)
> Nevertheless, sprintf() behaviour should be specified in the C99 spec, and not
> the IEEE-754 spec - even though the c99 spec must deal with IEEE values.

Before I give some information about current standards and what is in the 754r
draft (since there have been some changes on this subject), I note that in your
bug report (what you posted on 2007-08-20), you just mentioned IEEE, but not
C99: "the output for sprintf is inconsistent with that expected for the default
selected IEEE rounding mode." This makes your arguments difficult to follow...

Now, C99 describes the behavior of the printf family in 7.19.6.1#13. For the
examples given in this bug report, C99 says that the result should be correctly
rounded. C99 does not say which result should be returned in case of a tie, but
in practice, it relies on the definition given in IEEE-754.

In 5.6, IEEE754-1985 also requires correct rounding for binary <-> decimal
conversions (though the range conditions are a bit different). This is
consistent with C99, and the result is specified by the "rounding direction".

IEEE754-1985 defines only one round-to-nearest mode, but in binary only! I
assume that's a defect that has been fixed in a later version (see below). Of
course, it can be *implicitly* generalized to decimal, but not the halfway cases
(the even-rounding notion wasn't introduced at that time: it was just said that
the least significant bit had to be 0, which makes sense only in binary).

LIA-2 says that halfway cases are implementation-defined, but if iec_559F =
true, then the semantics is completely defined by IEC 60559 (which is, AFAIK,
IEEE-754, possibly revised): "ties are rounded to even last digit". It also says
that this is the rounding used by the conversions. So, glibc conforms to LIA-2 +
IEC 60559, but not Microsoft's library.

Now, the latest draft (1.4.0) of IEEE754r (which will probably be more or less
the final version) defines two round-to-nearest modes: roundTiesToEven and
roundTiesToAway (I think this is self-explanatory). It also says:

"An implementation of this standard shall provide roundTiesToEven. It shall be
the default rounding-direction mode for results in binary formats. The default
rounding-direction mode for results in decimal formats is language-defined, but
should be roundTiesToEven. A decimal implementation of this standard shall
provide roundTiesToAway as a user-selectable rounding-direction mode.  The
rounding mode roundTiesToAway is optional for binary."

This completely justifies the glibc behavior, at least currently. Of course, the
C standard doesn't define yet which rounding-direction mode is used for decimal
results, but when the choice will be made (if it is made), it will probably be
roundTiesToEven, as suggested by IEEE754r and LIA-2.

Finally, I don't think that many programs rely on a roundTiesToAway behavior of
binary-to-decimal conversion in halfway cases as most binary values are not
representable exactly in decimal. Indeed, whatever choice is made for halfway
cases, there are problems to round values of the form xxx.525 to binary and back
to decimal with 2 fraction digits (depending on xxx, you'll obtain either xxx.52
or xxx.53). You really need a decimal arithmetic or some form of emulation.

-- 


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.