errors for very large right shifts

[p6rt]

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

Searchable as RT126940$

[p6rt]

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]

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]

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

[p6rt]

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