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

Jump to bottom

Wrong math in Int + Int #2157

Closed
zoffixznet opened this issue Jul 31, 2018 · 3 comments
Closed

Wrong math in Int + Int #2157

zoffixznet opened this issue Jul 31, 2018 · 3 comments
Assignees
@zoffixznet
Labels
BLOCKER Preventing the next release of rakudo, or just needing attention before the release math regression Issue did not exist previously

Comments

@zoffixznet
Copy link
Contributor

zoffixznet commented Jul 31, 2018 •
edited

Result should be 9930972392403502

m: dd 9930972392403501 + 1;
rakudo-moar 38de1e512: OUTPUT: «9930972392403501␤»

Bisects to b61b3c7

The problem is present on both 64-bit and 32-bit systems
@AlexDaniel AlexDaniel added regression Issue did not exist previously BLOCKER Preventing the next release of rakudo, or just needing attention before the release labels Jul 31, 2018
@zoffixznet
Copy link
Contributor Author

Strangely, the problem doesn't occur if I rip out the nqp guts used and use them directly:

<Zoffix_> m: use nqp; dd nqp::box_i(nqp::atpos(nqp::radix(10, '9930972392403501', 0, 2), 0), Int)
    + nqp::box_i(nqp::atpos(nqp::radix(10, '1', 0, 2), 0), Int)
<camelia> rakudo-moar 42595c27d: OUTPUT: «9930972392403502␤»

@zoffixznet
Copy link
Contributor Author

Looks like bisection isn't quite the full story. In pure NQP, same problem exists:

nqp: say(9930972392403501 + 1);
nqp-moarvm: OUTPUT: «9930972392403501␤»

@zoffixznet zoffixznet self-assigned this Aug 1, 2018
@MasterDuke17
Copy link
Contributor

Seems like it's related to Raku/nqp#363. My WIP NQP branch that switches to using int behavior by default doesn't have this problem.

zoffixznet added a commit that referenced this issue Aug 1, 2018
@zoffixznet
Fix wrong math with largish Ints
fec1bd7 
Fixes R#2157 #2157

The cause of the bug is NQP apparently uses doubles to handle its
ints[^1]. 2**52 is the limit under which every number is representable
in a double, which is why when we bumped up[^2] the point at which we
switched to bigints in Rakudo to be over that limit, we brought in the
NQP's limitation into Perl 6 land.

Fix by dialing down the switch to bigint to occur before we go over the
2**52 limit. The NQP Issue[^1] will resolve the problem in NQP land and
once that's done, I presume we can bump up the limit in rakudo once again.

[1] N#363 Raku/nqp#363
[2] b61b3c7
@zoffixznet zoffixznet mentioned this issue Aug 1, 2018
Closed
zoffixznet added a commit to Raku/roast that referenced this issue Aug 1, 2018
@zoffixznet
Cover largish Int math on hex, bin, and octals
e59fbd9 
Part of cover for R#2157 rakudo/rakudo#2157
ugexe pushed a commit to Raku/roast that referenced this issue Dec 15, 2018
@zoffixznet @ugexe
Cover Int math for non-double-representables
f46a2ca 
Closes rakudo/rakudo#2157 R#2157
Rakudo fix: rakudo/rakudo@fec1bd74f9
ugexe pushed a commit to Raku/roast that referenced this issue Dec 15, 2018
@zoffixznet @ugexe
Cover largish Int math on hex, bin, and octals
78c2db9 
Part of cover for R#2157 rakudo/rakudo#2157
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@zoffixznet zoffixznet

Labels
BLOCKER Preventing the next release of rakudo, or just needing attention before the release math regression Issue did not exist previously
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@AlexDaniel @zoffixznet @MasterDuke17