Skip Menu |
Report information
Id: 126968
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: grondilu [at] yahoo.fr
Cc:
AdminCc:

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



To: rakudobug [...] perl.org
From: Lucien Grondin <grondilu78 [...] gmail.com>
Subject: [BUG] wrong output for 1000.fmt("%e") and 1_000_000.fmt("%e")
Date: Sat, 19 Dec 2015 22:19:47 +0100
Download (untitled) / with headers
text/plain 344b
$ perl6 --version
This is Rakudo version 2015.11-686-g09aaf93 built on MoarVM version 2015.11-106-g7545aa9
implementing Perl 6.b.

$ perl6 -e 'printf "%e\n", $_ for 1, 10, 100 ... 1_000_000;'
1.000000e+00
1.000000e+01
1.000000e+02
10.000000e+02
1.000000e+04
1.000000e+05
10.000000e+05

Outputs for 1_000 and 1_000_000 are not what they should.
Subject: Re: [perl #126968] [BUG] wrong output for 1000.fmt("%e") and 1_000_000.fmt("%e")
Date: Mon, 21 Dec 2015 15:29:08 +0100
To: "grondilu [...] yahoo.fr (via RT)" <perl6-bugs-followup [...] perl.org>
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Download (untitled) / with headers
text/plain 1.4k
Show quoted text
> On 19 Dec 2015, at 22:19, grondilu@yahoo.fr (via RT) <perl6-bugs-followup@perl.org> wrote: > > # New Ticket Created by grondilu@yahoo.fr > # Please include the string: [perl #126968] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=126968 > > > > $ perl6 --version > This is Rakudo version 2015.11-686-g09aaf93 built on MoarVM version > 2015.11-106-g7545aa9 > implementing Perl 6.b. > > $ perl6 -e 'printf "%e\n", $_ for 1, 10, 100 ... 1_000_000;' > 1.000000e+00 > 1.000000e+01 > 1.000000e+02 > 10.000000e+02 > 1.000000e+04 > 1.000000e+05 > 10.000000e+05 > > Outputs for 1_000 and 1_000_000 are not what they should.
I assume this is some kind of roundoff error when using floating point calculations to determine to go to the next power: $ 6 'printf "%e\n",$_ for 11, 110, 1100 ... 1_100_000' 1.100000e+01 1.100000e+02 1.100000e+03 1.100000e+04 1.100000e+05 1.100000e+06 seems pretty ok, but then the value is not near the boundary. This seems to be happening inside nqp::sprintf , and thus is really an NQP bug, or an underlying math lib bug. This reminds me of a bug my navigator has: when the distance gets below 10 km, it will show one digit of accuracy (like in 9.9). However, the cutoff point is wrong, because if the value is still 9.95 km or above, it will round to 10, and thus show 10.0 for a little while. Not sure whether this anything to do with it. Liz


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