1. Re: Peculiar IEEE Bug...
Lucius Hilley III <lhilley at CDC.NET> wrote:
>Anyone thing to test those IEEE numbers in another language?
>Visual Basic or Quick Basic or Java or Something else.
>Mayby Perl? That would give more of a hint to whether it is
>Watcom C or IEEE standard that causes the error.
Well, I tested our three original values (-1e-308, -2e-308, -3e-308) in
QuickBasic, and the problem doesn't seem to be the IEEE standard. QB
correctly evaluated each of the three values as being less than zero.
I then modified my QB program to write out the internal representations of
those three values to a random-access binary file, so I could read them in
with Euphoria and get their values with float64_to_atom(). Euphoria imports
the values 100% correctly -- no extraneous decimal values -- but still
evaluates them wrong!! -1e-308 and -2e-308 still come out as greater than
zero, while -3e-308 comes out correctly as less than zero.
Then I decided to see just how accurately Euphoria is converting things
internally. I re-created the three atom values in Euphoria, and used
atom_to_float64() to write them out to another file. I did a file-compare,
and UH-OH -- the first two bytes of each 8-byte value came out differently!
I re-read the three atoms back into Euphoria, and they come in just a tad
wrong -- the last two or three digits of the decimal don't come in as zeroes
from Euphoria's output as they did from the QB output.
So, was this perhaps a problem with atom_to_float64()? I decied to
double-check if Euphoria was creating its atom-values correctly. After all,
I gave QB -1 * 10 ^ -308, and it gave me exactly -1.000000000000000e-308, so
Euphoria should be able to do things just as accurately as QB, right? Boy,
was I wrong -- when I assign -1e-308 to atom a, and print it out with
printf(1, "%.15e", a), I end up with -1.000000000000034e-308!!!! And I get
the exact same value if I assign -1 * power(10, -308) to a!!! So the problem
isn't in atom_to_float64() -- the problem is that Euphoria doesn't even
*create* its atom values accurately to begin with! There's a scary
thought...
So, it seems we may have a couple problems here:
1) Euphoria handles *imported* binary representations of 8-byte float values
correctly, but can't *create* them accurately.
2) Even if they're imported as 100% correct, Euphoria still evaluates values
between -1e-308 and approx. -2.225e-308 as being *positive*.
From what I've found, I'd say the problem is with either the interpreter or
Watcom C. Regardless, the fact that Euphoria can't create -1e-308 without
turning it into -1.000000000000034e-308 disturbs me greatly. What other
little inaccuracies are lurking under the hood?
Anybody else come up with similar/differing results?
Gabriel Boehme
