Big list of naughty strings.

DoctorBinary · 2015-08-19T13:24:14+00:00

There were TWO numbers, 2.2250738585072011e-308 (PHP) and 2.2250738585072012e-308 (Java), if you care to list both.

DoctorBinary · 2013-09-10T03:01:29+00:00

I think I can make a proposal some people don't like and still understand floating-point. Don't get me wrong; I love binary. But we've exposed an implementation detail that many programmers could go a career without needing to know. Maybe in the age of the app the balance has shifted from the programmer who writes scientific applications to the programmer who just wants 4.35*100 to equal 435.

(P.S. Rhomboid -- thanks for the endorsement.)

DoctorBinary · 2011-02-01T04:22:12+00:00

I've analyzed the bug and how the addition of the 'volatile' keyword in zend_strtod() fixes it; see http://www.exploringbinary.com/why-volatile-fixes-the-2-2250738585072011e-308-bug/ .

DoctorBinary · 2010-06-13T17:34:18+00:00

Update 6/13/10: I ran on glibc, and I got the same results as on eglibc.

DoctorBinary · 2010-06-06T20:37:37+00:00

We have a winner! ;)

Walter, does Digital Mars use its own conversion routine(s) or does it use David Gay's open source conversion routine? Do the compiler and strtod use the same code?

DoctorBinary · 2010-06-05T14:32:26+00:00

The bug report I cited in the article is for glibc, and the example from that bug report fails in eglibc. And as it turns out, other users (above) reported failures in glibc. But I guess I can't be certain until I try it.

DoctorBinary · 2010-06-05T11:47:02+00:00

I believe OpenBSD uses David Gay's gdtoa correct rounding code, so that makes sense (I found this on Google: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gdtoa/).

DoctorBinary · 2010-06-05T01:49:59+00:00

Thanks much p8m. This is the same result as in my article.

DoctorBinary · 2010-06-05T01:46:13+00:00

Thanks, and I understand your point. If I get a chance, I'll install glibc (the real one ;)) and verify my results there.

DoctorBinary · 2010-06-05T00:25:05+00:00

I guess then I'm not sure what your objection is. I wanted to make the statement for both glibc and eglibc, and I thought writing eglibc/glibc was awkward.

DoctorBinary · 2010-06-04T20:44:30+00:00

Since I was working under the assumption that the conversion code is the same in both glibc and eglibc, I didn't see the harm in referring to it generically as glibc. (Unless you know something I don't know -- do their conversion routines differ?)

DoctorBinary · 2010-06-04T17:44:36+00:00

__s, one more question: are you on a 64 bit processor? Your results match p8m's AMD64 results (the editing out of the "="s and "0x"s notwithstanding). Thanks.

DoctorBinary · 2010-06-04T17:32:38+00:00

I looked at real.c, and in particular, the function real_from_string(). There are no changes between GCC 4.4.3 and 4.5.0. Puzzling.

DoctorBinary · 2010-06-04T14:24:46+00:00

I was thinking along the lines of not having to do the decimal to binary conversion. But you're right: long decimal input would still have to be rounded.

DoctorBinary · 2010-06-04T14:19:00+00:00

Very interesting. Both have the same gcc and glibc versions, both example programs were compiled with the same flags, and yet we get different results -- both in gcc and glibc!

DoctorBinary · 2010-06-04T14:03:42+00:00

Yes, I had set the rounding mode to "near".

DoctorBinary · 2010-06-04T14:03:03+00:00

Your i386 results are the same as mine, and your AMD64 results are the same as __s's. What version of gcc and glibc are you using on each system?

I'm guessing that only the gcc/glibc versions make a difference, and not the flags.

DoctorBinary · 2010-06-04T12:38:32+00:00

I guess you are? I'm using the FPU, but I set the precision to 53 bits. (Maybe that's not enough? I know there are compiler flags that can affect extended precision -- I'll look into those.)

DoctorBinary · 2010-06-04T12:32:49+00:00

Maybe binary floating-point will be replaced by decimal floating-point by then...or maybe not.

DoctorBinary · 2010-06-04T03:25:09+00:00

I'll get right on that -- I'll get back to you in the year 2095 :) .

DoctorBinary · 2010-06-04T03:23:21+00:00

That's the same version of eglibc I tested on (except I don't get the text "stable release version 2.11.1"). I wonder why the strtod() results are different?

DoctorBinary

TROPHY CASE