On Mon, 07 Nov 2016 03:50:49 -0800, masak wrote: > <MARTIMM> Wondering what the highest number is below Inf and lowest > above -Inf > <masak> MARTIMM: for the Num type, there's a highest representable > number below Inf > <masak> m: say 1e308 > <camelia> rakudo-moar 1c425f: OUTPUT«1e+308» > <masak> this is the largest Num below Inf I can get Rakudo to > represent. > <geekosaur> 1.7976931348623157081e+308 on x86_64 > <geekosaur> (and probably x86) > <masak> I expected it to be something like that, but the cutoff in > Rakudo was at exactly 1.000e308 > <masak> maybe some artificial limit has been put in somewhere for > safety reasons > <masak> m: say 1.7976931348623157081e200 * 1e108 > <camelia> rakudo-moar 1c425f: OUTPUT«1.79769313486232e+308» > <masak> a-ha :) > <masak> so Rakudo can represent them, just not with > scientific-notation number literals > <masak> I... would be tempted to call that a bug. > * masak submits rakudobug
The issue was due to calculations involved during the number's parsing, where the base value was first multiplied by enough powers of 10 to make it fraction-less and then multiplied by "e" powers of 10. For numbers close to the limit, this caused overflow to Inf before the final step (of dividing the number back) could be done. So 1.1e307 overflown, 1.1e306 wouldn't, but 1.11e306 would, because 1.11 was turned into 111 in mid-step. Fixed in https://github.com/rakudo/rakudo/commit/729d7e34124827a4e0b772b049be95cf911dd7cf Tests added in https://rt.perl.org/Public/Bug/Display.html?id=130039
