On Wed, 16 Dec 2015 18:34:42 -0800, zef...@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»
