On Fri, Apr 16, 2021 at 10:21 AM Ralph Mellor <ralphdjmel...@gmail.com> wrote:
[snip] > > my int $i = ...; > my num $n = $i; > > The conversion from int to num looks sane. Of course, we can't assign 64 bit values to an int, so I switched to the 63-bit values 9223372036854775296 and 9223372036854775295. The first of those should assign to the double as 9.223372036854776e+18 (0x1p+63), and that's exactly what happens for both the 'num' and 'Num' types: C:\>raku -e "my int $i = 9223372036854775296; my num $n = $i; say $n;" 9.223372036854776e+18 C:\>raku -e "say 0e0 + 9223372036854775296" 9.223372036854776e+18 However, the second of those integers should assign to the double 9.223372036854775e+18 (0x1.fffffffffffffp+62) - yet this happens only for the 'num' case: C:\>raku -e "my int $i = 9223372036854775295; my num $n = $i; say $n;" 9.223372036854775e+18 C:\>raku -e "say 0e0 + 9223372036854775295" 9.223372036854776e+18 I don't think it's a big deal if that is deemed to be NOT buggy. We would just have to be mindful of avoiding Nums when we're not prepared to accept that the usual "round to nearest, ties to even" rule might not be enforced. Mind you, it's hard to work out just what rounding rule *is* being enforced - it's definitely not one that I've ever encountered before. With "Num" I don't get the correct result until the value drops to 9223372036854775231. C:\_32>raku -e "say 0e0 + 9223372036854775232" 9.223372036854776e+18 C:\_32>raku -e "say 0e0 + 9223372036854775231" 9.223372036854775e+18 In binary 9223372036854775232 is: 0.11111111111111111111111111111111111111111111111111111 0111000000E63 and 9223372036854775231 is: 0.11111111111111111111111111111111111111111111111111111 0110111111E63 (I've inserted a space between the 53rd and 54th digits.) It's hard to come up with a rule that decrees that those 2 values should round to different 53-bit forms. Though there seems to be a pattern emerging: 9223372036854775295 - 9223372036854775231 == 64 and from my initial post in this thread: (18446744073709551615 - 1024) - (18446744073709551615 - 1088) == 64. I suspect some little optimization trick might be doing something unexpected. > I hope to get time to respond to your earlier posts this weekend. > > No rush, and please, don't stress over any of this. Cheers, Rob
