OpenEuphoria

Re: Current implementation of exp() is faulty.

• Posted by Jason Gade <jaygade at ya?oo.co?> May 08, 2008
• 776 views

CChris wrote:
> What I was trying to explain is that it is not a problem.
> The reason why it is not a problem is that the many variants of a string that
> will convert to the same single 8-byte sequence start with the same digits,
> usually the first 17 or 18, bar exceptional cases like
> 0.99999999999999999999999999999999999999
> and 1.0.

You've got this backwards: the parser will only parse the first 17 decimal
characters into exactly *one* 64-bit double value. However, going from a 64-bit
double value to a string of digits, more than one 64-bit value will match up to
the same string of 16 digits.

> Since the strings I pasted into my code are way longer than that, the
> imprecision
> should be largely beyond what the parser will ever process. As a result, in
> spite of your point, it should return the proper 8-byte sequence.
> 
> In order to eliminate the exceptional cases mentioned above, I also tried
> values
> that are not integers, and either fully or not representable as a double. The
> discrepancies remain.
> 
> CChris

After the first 17 digits it doesn't matter and anything more is just noise. The
value is not refined further, even if it could be.


I quote Matt again:
"The 18th or higher digit, however, will never have an effect on the resulting
atom."

And:

"there's not really a one-to-one correspondence between the decimal digits and
the bits in the resulting atom."

--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.