Re: strtod bugs

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Jim Meyering on 4/1/2008 1:02 AM:
|> Wow - gnulib's version of strtod really IS inaccurate.  The buildbot is
|> still showing failures, since 5 * pow (10.0, -1) != 0.5.  Any suggestions
|> on how to make this test pass?  Would it be acceptable (for now) to just
|> check that the result is within 1 or 2 ULP of the correct answer?
|
| Sounds good.

Done as follows.  FLT_EPSILON represents a 2-ulp error for 0.5; if the
autobuilder still doesn't pass with the 1-ulp allowance, we can change <
to <=.  (Or, to avoid iterating, can someone with access to a machine that
is failing use gdb to determine what rpl_strtod is actually returning in
place of 0.5?)

And in case it's not obvious to people reading this thread - I really
don't like introducing inaccurate algorithms.  But it is a much faster
path to permit inaccuracies for now, so that I can release M4 1.4.11 with
documented inaccuracies (and in turn release Autoconf 2.62) this week,
than it is to figure out how to port an accurate decimal-to-binary
conversion algorithm to strtod.c; and the recent flurry of patches to
strtod.c have not made gnulib's version any less accurate than it
previously was, rather, it is exposing those inaccuracies on more platforms.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkfyLaEACgkQ84KuGfSFAYDBVQCeN2s78sdN5heZSzIj0zvdCnuZ
gDoAnjX9AXCgVYQz+MlR19nCnpNRAxLN
=HSnm
-----END PGP SIGNATURE-----

>From d9c1fb5a5d6eb4c44e65918c0517a504b6d8f504 Mon Sep 17 00:00:00 2001
From: Eric Blake <address@hidden>
Date: Tue, 1 Apr 2008 06:34:34 -0600
Subject: [PATCH] For now, cater to gnulib strtod inaccuracies.

* tests/test-strtod.c (main): Allow 1-ulp error on expected
fractional results.  While not as nice from a QoI perspective, it
is a quicker patch than correctly implementing decimal to binary
rounding.

Signed-off-by: Eric Blake <address@hidden>
---
 ChangeLog           |    8 ++++++++
 tests/test-strtod.c |   10 ++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c02f097..aa673e4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2008-04-01  Eric Blake  <address@hidden>
+
+       For now, cater to gnulib strtod inaccuracies.
+       * tests/test-strtod.c (main): Allow 1-ulp error on expected
+       fractional results.  While not as nice from a QoI perspective, it
+       is a quicker patch than correctly implementing decimal to binary
+       rounding.
+
 2008-03-31  Eric Blake  <address@hidden>
 
        Guarantee a definition of NAN.
diff --git a/tests/test-strtod.c b/tests/test-strtod.c
index aff36ee..d7898be 100644
--- a/tests/test-strtod.c
+++ b/tests/test-strtod.c
@@ -157,7 +157,10 @@ main ()
     double result;
     errno = 0;
     result = strtod (input, &ptr);
-    ASSERT (result == 0.5);
+    /* FIXME - gnulib's version is rather inaccurate.  It would be
+       nice to guarantee an exact result, but for now, we settle for a
+       1-ulp error.  */
+    ASSERT (abs (result - 0.5) < FLT_EPSILON);
     ASSERT (ptr == input + 2);
     ASSERT (errno == 0);
   }
@@ -237,7 +240,10 @@ main ()
     double result;
     errno = 0;
     result = strtod (input, &ptr);
-    ASSERT (result == 0.5);
+    /* FIXME - gnulib's version is rather inaccurate.  It would be
+       nice to guarantee an exact result, but for now, we settle for a
+       1-ulp error.  */
+    ASSERT (abs (result - 0.5) < FLT_EPSILON);
     ASSERT (ptr == input + 4);
     ASSERT (errno == 0);
   }
-- 
1.5.4