OpenEuphoria

Re: Current implementation of exp() is faulty.

• Posted by CChris <christian.cuvier at agriculture?gouv.fr> May 08, 2008
• 724 views

Jason Gade wrote:
> 
> 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.

Both quootes are right, but we still don't understand each other.

The pasted in strings come from a professional software specialised in maths
computations, not from anything written in Euphoria. So I'm sure most of the
digits there are not noise. To guard against any cutoff effect, I requested many
more digits than should matter to compute a double.
As I said, that way, even if the last few were noise, it wouldn't matter. All
relevant digits are guaranteed.

Which Euphoria parser are you talking about?
Neither get() nor value() are invoked. 
When exwc.exe reads "atom_to_float64(1565146.159101750457681234), it uses an
internal routine, called my_sscanf() in source\scanner.e, which turns a string
into atoms. This routine does not check how many decimal places are given. But
indeed, the 18th digit will very rarely matter at all.

I tried the implementation I suggested, but it is closer to the exact value only
for x>=10 or slightly below. For x greater than say 20, it is almost good.

CChris