public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "hack at watson dot ibm dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/3479] Incorrect rounding in strtod() Date: Mon, 05 Feb 2007 18:32:00 -0000 [thread overview] Message-ID: <20070205183152.6208.qmail@sourceware.org> (raw) In-Reply-To: <20061107172025.3479.hack@watson.ibm.com> ------- 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.
next prev parent reply other threads:[~2007-02-05 18:32 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-11-07 17:20 [Bug libc/3479] New: " hack at watson dot ibm dot com 2007-02-04 19:37 ` [Bug libc/3479] " john at thesalmons dot org 2007-02-04 19:44 ` john at thesalmons dot org 2007-02-05 16:48 ` joseph at codesourcery dot com 2007-02-05 18:32 ` hack at watson dot ibm dot com [this message] 2007-02-05 21:54 ` john at thesalmons dot org 2007-02-12 17:04 ` jakub at redhat dot com 2007-10-22 14:47 ` vincent+libc at vinc17 dot org 2009-07-15 14:59 ` Sylvain dot Pion at sophia dot inria dot fr 2009-07-15 15:23 ` Sylvain dot Pion at sophia dot inria dot fr 2009-07-15 15:50 ` vincent+libc at vinc17 dot org 2009-07-15 16:21 ` Sylvain dot Pion at sophia dot inria dot fr 2010-06-04 1:02 ` exploringbinary at gmail dot com 2010-06-04 1:03 ` exploringbinary at gmail dot com 2010-09-02 16:25 ` schwab at linux-m68k dot org [not found] <bug-3479-131@http.sourceware.org/bugzilla/> 2011-11-12 16:11 ` mwelinder at gmail dot com 2012-05-02 10:03 ` jsm28 at gcc dot gnu.org 2012-05-02 15:23 ` bugdal at aerifal dot cx 2012-05-02 16:01 ` floitsch at google dot com 2012-05-02 16:55 ` joseph at codesourcery dot com 2012-08-10 23:41 ` jsm28 at gcc dot gnu.org 2012-08-25 15:28 ` jsm28 at gcc dot gnu.org 2012-08-25 15:30 ` floitsch at google dot com 2012-08-27 16:13 ` jsm28 at gcc dot gnu.org 2013-11-12 16:43 ` exploringbinary at gmail dot com 2014-02-16 16:57 ` jackie.rosen at hushmail dot com 2014-05-28 19:44 ` schwab at sourceware dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20070205183152.6208.qmail@sourceware.org \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).