Skip Menu |
Report information
Id: 128817
Status: resolved
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: zefram [at] fysh.org
Cc:
AdminCc:

Severity: (no value)
Tag: Bug
Platform: (no value)
Patch Status: (no value)
VM: (no value)



To: rakudobug [...] perl.org
From: Zefram <zefram [...] fysh.org>
Date: Tue, 2 Aug 2016 17:51:07 +0100
Subject: [BUG] Num.perl doesn't round-trip numeric value
Download (untitled) / with headers
text/plain 249b
Show quoted text
> (1180591620717411303424.0e0).Int
1180591620717411303424 Show quoted text
> (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 different Num value. -zefram
Download (untitled) / with headers
text/plain 948b
On Tue Aug 02 09:51:31 2016, zefram@fysh.org wrote: Show quoted text
> > (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 different Num value.
Double-precision floating point (which is essentially what "e0" does) generally has only 15-17 digits of decimal precision. I don't know that we should expect .perl or any other operation on Num values to be preserving more precision than that. Show quoted text
> (1180591620717411303424.0e0+0).perl
1.18059162071741e+21 In particular, note that the following produce results that are mathematically incorrect but are still within the expected range of behavior for floating-point (Num) values: Show quoted text
> (1180591620717411303424.0e0 + 1.0 ).Int
1180591620717411303424 Show quoted text
> (1180591620717411303424.0e0 + 10 ).Int
1180591620717411303424 Pm
To: "Patrick R. Michaud via RT" <perl6-bugs-followup [...] perl.org>
Date: Tue, 2 Aug 2016 19:32:56 +0100
Subject: Re: [perl #128817] [BUG] Num.perl doesn't round-trip numeric value
From: Zefram <zefram [...] fysh.org>
Patrick R. Michaud via RT wrote: Show quoted text
>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 d'etre. The value I'm using in this example is 2**70, a very round number that is easily represented in floating point. If the lengthy decimal representation is putting you off, consider Show quoted text
> (2e0**70).perl.EVAL == 2e0**70
False Show quoted text
> > (1180591620717411303424.0e0 + 1.0 ).Int
> 1180591620717411303424
> > (1180591620717411303424.0e0 + 10 ).Int
> 1180591620717411303424
These are as expected: floating point rounding applies, and the results obtained are the closest representable values to the mathematically correct result. This is a red herring. My example doesn't invoke any operation requiring rounding. The initial decimal literal has the exact representable value, which gets represented correctly as a Num. I don't then perform any arithmetic on it. -zefram
From: "Patrick R. Michaud" <pmichaud [...] pobox.com>
To: Zefram <zefram [...] fysh.org>
Date: Tue, 2 Aug 2016 14:05:58 -0500
Subject: Re: [perl #128817] [BUG] Num.perl doesn't round-trip numeric value
CC: "Patrick R. Michaud via RT" <perl6-bugs-followup [...] perl.org>
Download (untitled) / with headers
text/plain 893b
On Tue, Aug 02, 2016 at 07:32:56PM +0100, Zefram wrote: Show quoted text
> 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 d'etre. > [...]
Okay. I'm agreeable to say that .perl (and perhaps sprintf where appropriate) should add two more digits of precision to the strings they produce, to preserve the round-trippiness of the values being represented. Show quoted text
> (1180591620717411303424e0).perl
1.18059162071741e+21 Show quoted text
> (1.18059162071741e+21).Int # not enough precision
1180591620717409992704 Show quoted text
> (1.180591620717411e+21).Int # still not enough
1180591620717411041280 Show quoted text
> (1.1805916207174113e+21).Int # okay, this works
1180591620717411303424 Pm
Subject: Re: [perl #128817] [BUG] Num.perl doesn't round-trip numeric value
To: "Patrick R. Michaud via RT" <perl6-bugs-followup [...] perl.org>
Date: Fri, 19 Aug 2016 22:13:56 +0100
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 235b
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
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 869b
On Tue, 02 Aug 2016 09:51:31 -0700, zefram@fysh.org wrote: Show quoted text
> > (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 different Num value. > > -zefram
Thank you for the report. This is now fixed. Fix: https://github.com/MoarVM/MoarVM/commit/067c0594103a025 https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8 https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344 https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b https://github.com/rakudo/rakudo/commit/8422d7b4e23678b https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1 https://github.com/rakudo/rakudo/commit/430266629f2e2a0 Test: https://github.com/perl6/roast/commit/dcdbcb31b43a0f6ec


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org