Re: Current implementation of exp() is faulty.
CChris wrote:
>
>
> 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.
Only for very small values of vary rare. :) Somewhat like the very large
values of 2 that yield 2 + 2 = 5.
In fact, my_sscanf usually doesn't make it as far as that before going off
course. It's fine for a few digits, and I'm not sure where it starts losing
it (and it probably depends on the number) but I think it rarely makes it
through all 17.
As I recall, I started looking at binary fractions, and converted them to
decimal representations. Or maybe the other way around. Either way, when
you look at something whose first non-zero is in the 18th digit of precision,
you need at least 54 bits to represent it. Since we never have more than
53, anything after 17 just doesn't matter. And sometimes, the 17th doesn't
matter either.
Matt
|
Not Categorized, Please Help
|
|
