-----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 [EMAIL PROTECTED]
-----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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
---
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 <[EMAIL PROTECTED]>
+
+ 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 <[EMAIL PROTECTED]>
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
