From @lizmat

[13​:04​:39] <lizmat> m​: my num32 @​arr = 1.1e0,1.2e0,1.3e0; my num32 $s = 0e0; for @​arr { $s += $_ }; say $s # jnthn, seems num32 is busted for meta ops
[13​:04​:40] <+camelia> rakudo-moar 748e69​: OUTPUT«-8589934592␤»
[13​:05​:20] <lizmat> m​: my num32 @​arr = 1.1e0,1.2e0,1.3e0; my num32 $s; for @​arr { $s += $_ }; say $s # jnthn​: worse if $s not initialized
[13​:05​:21] <+camelia> rakudo-moar 748e69​: OUTPUT«0␤»

From @FROGGS

This makes it pass but my gut feeling is that this is not sensible​:
https://gist.github.com/FROGGS/c98f455874e50d39ff75

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

From @AlexDaniel

This is now fixed​:
my num32 @​arr = 1.1e0,1.2e0,1.3e0; my num32 $s = 0e0; for @​arr { $s += $_ }; say $s

¦2015.11,ec18f24d2^​: «-8589934592␤»
¦ec18f24,2015.12,HEAD(5929887)​: «3.60000014305115␤»

(2015-12-17) rakudo/rakudo@ec18f24

The second case returns NaN, because uninitialized nums seem to be NaNs. I guess that's ok?

｢testneeded｣

On 2015-03-16 05​:08​:33, elizabeth wrote​:

[13​:04​:39] <lizmat> m​: my num32 @​arr = 1.1e0,1.2e0,1.3e0; my num32
$s = 0e0; for @​arr { $s += $_ }; say $s # jnthn, seems num32 is
busted for meta ops
[13​:04​:40] <+camelia> rakudo-moar 748e69​: OUTPUT«-8589934592␤»
[13​:05​:20] <lizmat> m​: my num32 @​arr = 1.1e0,1.2e0,1.3e0; my num32
$s; for @​arr { $s += $_ }; say $s # jnthn​: worse if $s not
initialized
[13​:05​:21] <+camelia> rakudo-moar 748e69​: OUTPUT«0␤»

From @zoffixznet

Tests​: Raku/roast@0d871001ffe8a2393c989d1c

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