[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-21 22:31 -------
(In reply to comment #11)
> (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.
> 

First, I have to thank you for the effort and time you have spent answering my
query.  It might not be the answer I would like, but it is a very complete
answer.  I will leave the body of your response reasonably intact to preserve
context, and add my comments interspersed.

> 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...

My humble apologies.  This was not my intention.  I simply assumed that the
problem had something to do with the IEEE rounding mode (correctly, it would
appear) and stated that in my bug report.

> 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.

This is interesting.  I wonder whether we could dig up a definition for the
phrase "correctly rounded".  You already know my opinion on what is meant by the
phrase.  Again, are we not assuming too much about the scope of the IEEE-754? 
>From what I understand, that document is describing how to round the result of
calculations, not how to round decimal numbers arithmetically.

> 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).

Wow.  That's an amazing amount of detail.

> 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.

I really don't have a problem with rounding to nearest even, if it is only
dealing with the 15th decimal place for double precision floating points.  When
we speak of rounding here, I do not believe it has anything at all to do with
binary to decimal conversion.

To the best of my knowledge, all 8 byte floating point values are stored to 15
decimals of precision (or 52 binary digits of precision).  The only instance
where it makes sense to round to nearest even value, is in the context of
averaging error for calculation results.

> 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.

One might assume that, but in practice math just doesn't work that way. 
Changing the rules for rounding math equations is like defining apple=pear and
then selling pear juice instead of apples.  Earlier on you say that C99 says
that the numbers "should be correctly rounded" when converted to decimal.  I
don't see any ambiguity in that statement.  I don't see any need for the C99
spec to provide any further clarification...

> 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.

As you say, there are many more numbers that are inexactly stored than those
which are exact.  It took a while for us to find the fact that our reports were
sometimes generating the wrong numbers.  It works most of the time.  Our problem
is that those reports are being used by investment houses to make decisions
sometimes worth billions, and we just cannot have those decisions made against
wrong numbers.

-- 


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.