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-09-22 23:09 -------
(In reply to comment #25)
> Since the late 80's I could quote the IEEE storage format without a second
> thought.

Knowing the format is not the same as knowing how FP works.

> Perhaps it is not common to have people query these things.  Everyone just
> seems to accept that "floating point is inaccurate" and are happy to leave
> it at that.

People are working to make it better. Since you need an arithmetic for financial
applications, you should know that work has been done in this way: decimal
floating-point, with some specific functions, defined in IEEE754r. But the glibc
doesn't support them yet (and decimal support is quite recent and incomplete in
GCC).

> > Double-precision numbers are binary numbers, not decimal numbers. Saying 
> > "15-digit precision" is misleading; 
> 
> I thought I was using the correct terminology when I said "15 decimals of
> precision" or phrased differently, "15 decimal digits of precision"...

FYI, you need 17 digits to make sure that no information is lost in the
conversions. Your "15 decimal digits of precision" is no more an approximation.

> > you should say "53-bit precision" since their representation is in binary.
> 
> well, not quite 53 bits, rather 52.

53, as you need to include the first bit 1 (to be consistent with other bases).
See the value of the C macro DBL_MANT_DIG on your platform, for instance.

> When you break it down, though, it's not even 52 bits, as you cannot ignore
> calculation and storage error.

No, you mix up "accuracy" and "precision". The precision is always 53 bits for
the double format (well, not taking subnormals into account). After
calculations, the precision remains the same, but the accuracy can decrease (and
it will, in general).

> MS stores the value
>   5000.525
> as
>   5000.524999999999600

This is not 5000.524999999999600, but a 53-bit value. The exact value (written
in decimal) is: 5000.524999999999636202119290828704833984375. But if you
understand floating point, you should know that and you should know why my
program returned the value you obtained. Not that my program is not some random
one, I could write it and find values that gave different rounding directions
because I understand floating point.

-- 


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]