[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-20 15:55 -------
(In reply to comment #9)

Ah- a spot of sanity and logical argument again rather than hurling insults.  Cool.

> (In reply to comment #8)
> > You and Microsoft really cannot both be right about this one, you know.
> 
> Something you don't seem to have understood: the standards do not specify how
> the halfway cases should be rounded. So, yes, glibc and Microsoft can be both
> right while yielding different results.

I actually took the time to scan the IEEE doc once I started to get some idea as
to what was going on here.  Perhaps you are right that I misunderstood at first.
 However:
  The standards doc describes exactly what should happen with halfway cases.  It
says that numbers should be rounded to the closest value, or if it is precisely
halfway, that the number should be rounded to the closest even value.
  What the document is describing has nothing to do with printf(), but
everything to do with the results of arithmetic operations.  That 15th decimal
of precision is always in doubt- there is inevitably an error associated.  
  What we do know is that for a large enough set of operations, the probability
for error will be the same for each operation, so essentially we can prevent the
error from being additive by rounding towards the closest even number in cases
where the representation is on a boundary.

Yes, you are theoretically correct that behavior for the same function in two
disparate libraries may differ without their implementation being wrong. 
Another way of saying this, is that the two libraries simply follow different
specifications.  However, This begs the question:  Which specification are we
following for the library, and which does Microsoft implement?

I would assume that Microsoft does at least loosely follow a standard. I believe
GLibC follows the C99 standard.

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.

When I speak of consistency, and getting back to my original example, the
results of printf("%.2f", 2597.525) and printf("%.2f", 2597.625) should not be
determined by the fact that the FPU can store 2597.625 precisely.  Note that
following the "round to closest even value" rule should have produced 2397.52
and 2397.62 if that were the issue here (.02 being the closest even value). 
Instead, we see 2397.53 and 2397.62.

What we really have, is a number 2597.625 which may be stored precisely with no
error at all.  Practical question is:  will the FTSE and their clients be happy
with us rounding that index value down to 2597.62 just because the FPU can store
that value precisely, whilst in the next breath rounding the index value
2597.525 up to 2597.53 because it cannot?

I don't know whether I am missing some obscure logic or reasoning here, and I am
the first to admit that I am not specialist in this area.

Please.  I really really really want a solution here.  I am not purposely trying
to be pig headed.  Apologies for reciprocating in my previous response, but I do
not appreciate being called egotistical and an idiot.

> > The current behaviour is correct only in how the FPU deals with rounding the
> > error at the 15'th decimal of precision.  That behaviour, and indeed the IEEE
> > specification has absolutely nothing to do with what printf() produces when
> > asked to represent a current value, which for 8 byte doubles is always stored
> > to 15 decimals of precision, as text.
> 
> The IEEE754-1985 standard also (partly) specifies binary to decimal conversions
> (see Section 5.6).

Didn't see that one-  will check. Thanks.


-- 


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.