From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6315 invoked by alias); 5 Feb 2007 18:32:08 -0000 Received: (qmail 6209 invoked by uid 48); 5 Feb 2007 18:31:52 -0000 Date: Mon, 05 Feb 2007 18:32:00 -0000 Message-ID: <20070205183152.6208.qmail@sourceware.org> From: "hack at watson dot ibm dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20061107172025.3479.hack@watson.ibm.com> References: <20061107172025.3479.hack@watson.ibm.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/3479] Incorrect rounding in strtod() X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00021.txt.bz2 ------- 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.