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

errors for very large right shifts #4879

Open
p6rt opened this issue Dec 17, 2015 · 4 comments
Open

errors for very large right shifts #4879

p6rt opened this issue Dec 17, 2015 · 4 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Dec 17, 2015

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

Searchable as RT126940$

@p6rt
Copy link
Author

p6rt commented Dec 17, 2015

From zefram@fysh.org

It seems to be intended (though it's not documented) that long bit shifts
produce the mathematically correct answer​:

123 +> (1 +< 10)
0

but for some particularly large right shift distances, this doesn't work​:

123 +> (1 +< 63)
123
123 +> ((1 +< 64) - 100)
155921023828072216384094494261248
123 +> ((1 +< 64) - 1)
246

Presumably these shift distance values are being subjected to some
bitwise reinterpretation after unboxing.

-zefram

@p6rt
Copy link
Author

p6rt commented Jun 5, 2017

From @zoffixznet

On Wed, 16 Dec 2015 18​:34​:42 -0800, zefram@​fysh.org wrote​:

It seems to be intended (though it's not documented) that long bit shifts
produce the mathematically correct answer​:

123 +> (1 +< 10)
0

but for some particularly large right shift distances, this doesn't work​:

123 +> (1 +< 63)
123
123 +> ((1 +< 64) - 100)
155921023828072216384094494261248
123 +> ((1 +< 64) - 1)
246

Presumably these shift distance values are being subjected to some
bitwise reinterpretation after unboxing.

-zefram

For record, all three of the problematic ones now throw. Is that the desired behaviour?

<Zoffix__> m​: say 123 +> ((1 +< 64) - 100)
<camelia> rakudo-moar 8efffb​: OUTPUT​: «Cannot unbox 64 bit wide bigint into native integer␤ in block <unit> at <tmp> line 1␤␤»
<Zoffix__> m​: say 123 +> ((1 +< 64) - 1)
<camelia> rakudo-moar 8efffb​: OUTPUT​: «Cannot unbox 64 bit wide bigint into native integer␤ in block <unit> at <tmp> line 1␤␤»
<Zoffix__> m​: say 123 +> (1 +< 63)
<camelia> rakudo-moar 8efffb​: OUTPUT​: «Cannot unbox 64 bit wide bigint into native integer␤ in block <unit> at <tmp> line 1␤␤»

@p6rt
Copy link
Author

p6rt commented Jun 5, 2017

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

@p6rt
Copy link
Author

p6rt commented Jun 5, 2017

From zefram@fysh.org

Zoffix Znet via RT wrote​:

For record, all three of the problematic ones now throw. Is that the
desired behaviour?

Not the desired behaviour, no. It's a massive improvement over giving
the wrong answer, and arguably fixes the bug qua bug, but it's still
less than awesome. It would be easy (and shouldn't even cause any loss
of usual-case performance) to make these cases give the right answer.

If the decision is for these cases throwing to be the final behaviour,
then this limitation on the bit shift operators should be documented.
(You don't need to specifically document that the operation will fail
if the right answer is too big to represent, but in this case the right
answer is very small.)

-zefram

@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