Patrick R. Michaud via RT wrote:
>Nums hold only 15-17 digits of precision, so sprintf("%f")
>likely has this one correct.
No, it does not have this correct. The value represented in the Num is
exactly 2**70, and the .Int accurately reflects that. It is the sprintf
that is failing to show the Num's value.
> 2**70
1180591620717411303424
> (2e0**70).Int
1180591620717411303424
> sprintf("%f", 2e0**70)
1180591620717410000000.000000
>In particular, the true value is *not* always available,
By "true value" I meant the value represented in floating point.
I did not mean the value directly represented by the decimal literal.
Your example here shows unavoidable (and correctly performed) rounding
in the decimal->float conversion. In my example I deliberately used a
value that could be exactly represented in floating point, so that this
decimal->float rounding would not arise. It is not the issue here.
It's sounding, in this and [perl #128817], rather as though you're
thinking about floating point precision entirely in decimal terms.
It is as if you think Num implements decimal floating point, though
empirically it clearly exhibits the arithmetic behaviour of ordinary
binary floating point. Is there perhaps some underlying design decision
for decimal floating point that hasn't been carried through?
-zefram
