Thank you for your email request. Your request ID is I-1549153
Thank you for your email request. Your request ID is I-1549154
On Tue, 02 Aug 2016 09:51:31 -0700, zef...@fysh.org wrote:
> > (1180591620717411303424.0e0).Int
> 1180591620717411303424
> > (1180591620717411303424.0e0).perl.EVAL.Int
> 1180591620717409992704
>
> The .perl.EVAL process ought to yield the same value we started with.
> It's coming back as a differe
On Tue, 02 Aug 2016 09:51:31 -0700, zef...@fysh.org wrote:
> > (1180591620717411303424.0e0).Int
> 1180591620717411303424
> > (1180591620717411303424.0e0).perl.EVAL.Int
> 1180591620717409992704
>
> The .perl.EVAL process ought to yield the same value we started with.
> It's coming back as a differe
Additional: the same problem arises with Complex.perl, where the real
or imaginary parts suffer this problem as Nums. Fixing this for Num
won't automatically fix it for Complex, because Complex.perl doesn't
invoke Num.perl.
-zefram
On Tue, Aug 02, 2016 at 07:32:56PM +0100, Zefram wrote:
> Patrick R. Michaud via RT wrote:
> >I don't know that we should expect .perl or any other operation on Num
> >values to be preserving more precision than that.
>
> I'd expect .perl to preserve whatever precision is there. Accurately
> repr
Patrick R. Michaud via RT wrote:
>I don't know that we should expect .perl or any other operation on Num
>values to be preserving more precision than that.
I'd expect .perl to preserve whatever precision is there. Accurately
representing the value, in a form understandable by .EVAL, is its
raison
# New Ticket Created by Zefram
# Please include the string: [perl #128817]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128817 >
> (1180591620717411303424.0e0).Int
1180591620717411303424
> (1180591620717411303424.0e0).perl.E
