OpenEuphoria

Re: Current implementation of exp() is faulty.

• Posted by CChris <christian.cuvier at agricu?ture.gou?.fr> May 08, 2008
• 742 views

Jason Gade wrote:
> 
> CChris wrote:
> > Didn't Matt incorporate his parsing improvements to the interpreter?
> > At any rate, the value provided corresponds to nearly 300 bits of precision.
> > Even if the lowest 50 are wrong (overly pessimistic), only 17 digits would
> > be
> > wrong, and the parser should retrieve the exact same value, since a double
> > only
> > stores 53 bits.
> > 
> > CChris
> 
> I've already replied to this, but the main thing is that from atom to string
> representation there is a many-to-one correlation. That is, several binary
> representations
> differing only in the least significant bits will translate into one string
> representation.
> 
> I'm trying to think of the mathematical term for it, but basically that means
> that the function is not reversible since you necessarily lose some
> information
> in the conversion and therefore the function cannot be inverted.
> 
> Even Matt's scientific.e has limits to parsing precision between
> decimal/string
> representation and the actual binary representation of a calculated number.
> 
> --
> 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.

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.
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