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.


  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: link
Be 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).