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