Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wrong output for 1000.fmt("%e") and 1_000_000.fmt("%e") #4892

Open
p6rt opened this issue Dec 19, 2015 · 3 comments
Open

wrong output for 1000.fmt("%e") and 1_000_000.fmt("%e") #4892

p6rt opened this issue Dec 19, 2015 · 3 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Dec 19, 2015

Migrated from rt.perl.org#126968 (status was 'open')

Searchable as RT126968$

@p6rt
Copy link
Author

p6rt commented Dec 19, 2015

From @grondilu

$ 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.

@p6rt
Copy link
Author

p6rt commented Dec 21, 2015

From @lizmat

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-archive.perl.org/perl6/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

@p6rt
Copy link
Author

p6rt commented Dec 21, 2015

The RT System itself - Status changed from 'new' to 'open'

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant