Patrick R. Michaud via RT wrote:
>It's not universally true that Num literals like these "work fine
>in other contexts" -- the pair of literals in the example given "work"
>because they differ in the fifteenth decimal digit of precision.
Once again, you're mistakenly supposing my complaint to be from a
decimal point of view and the problem explained by rounding in the
decimal->float conversion. This is not the case. Both of my literals
directly represent values that are exactly representable in floating
point, and in most contexts they correctly yield Nums with those values.
>In short, it's "normal" (expected behavior) for mathematical errors to
>occur beyond 15 digits of precision in Num (floating point) values.
It is not normal for the same literal to represent two different values
when used twice. The decimal->float rounding doesn't account for this.
More information: upon further experimentation, it seems that the critical
issue is whether the two literals are compiled together. Any expression
containing both literals has them actually yield the same value, and
it's the proper value of whichever literal came first:
> (1180591620717411303424e0, 1180591620717409992704e0).map(*.Int)
(1180591620717411303424 1180591620717411303424)
> (1180591620717409992704e0, 1180591620717411303424e0).map(*.Int)
(1180591620717409992704 1180591620717409992704)
> ("1180591620717411303424e0", "1180591620717409992704e0").map(*.EVAL.Int)
(1180591620717411303424 1180591620717409992704)
Perhaps the compiler is coalescing the constants based on them having
identical .WHICH values, for which see [perl #128819]. The expression
"2e0**70" doesn't get the same treatment, so the coalescing can't be
happening after constant folding, if that gets folded.
-zefram
