From @masak

<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

From @zoffixznet

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 rakudo/rakudo@​729d7e34124827a4e0b772b049be95cf911dd7cf
Tests added in https://rt.perl.org/Public/Bug/Display.html?id=130039

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

@zoffixznet - Status changed from 'open' to 'resolved'