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/3479] Incorrect rounding in strtod()


------- Additional Comments From hack at watson dot ibm dot com  2007-02-05 18:31 -------
There are two issues here:  compile-time and run-time match, and correct rounding.

The second issue is one way to achieve the first:  if both environments round
correctly all given digits, the results will match no matter how this is
implemented.  A more common approach is to reuire the use of the same library
routine in both environments -- but that is difficult to guarantee as libraries
evolve, possibly in the direction of supporting more correctly-rounded digits.

Another method is to legislate some imperfect method, e.g. first round (in
decimal) to some standard number of digits, then convert that with correct
rounding to the target binary format.  

It looks like gcc took the first approach (using gmp as its high-precision
engine), but has a simple bug: an invalid shortcut that fails for numbers that
are very close to a rounding threshold, as is John's example.

My program PHL converts to various precisions; K=Binary128, J=Binary64 (aka
double), and I=Binary32 (aka float); the L modifier overrides the natural length
of the format, and I use it show bits way beyond the rounding point.  The number
is indeed slightly larger than a half-way float, but it takes extended precision
to see it; 10-byte Intel long double (a format that I don't support directly)
looks like it would just show one non-zero tail bit.

The input string is:
"1.00000005960464477550"
PHL K    1.00000005960464477550= *  3FFF0000 01000000 00020482 42F2FF67
PHL J    1.00000005960464477550= *  3FF00000 10000000
PHL JL16 1.00000005960464477550= *  3FF00000 10000000 00204824 2F2FF66C
PHL IL16 1.00000005960464477550= *  3F800000 80000000 01024121 797FB363
PHL IL8  1.00000005960464477550= *  3F800000 80000000
PHL I    1.00000005960464477550= *  3F800001

Btw, such numbers can be generated (for any precision) by using Continued
Fraction expansions of ratios of powers of two and five.

Michel


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=3479

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