<span style="font-family: courier new,monospace;"></span><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> Rate eval for map sum</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">eval 28528/s -- -93% -94% -99%
</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">for 399865/s 1302% -- -14% -85%</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">
map 464529/s 1528% 16% -- -83%</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">sum 2738845/s 9500% 585% 490% --</span></blockquote><div><br><span style="font-family: courier new,monospace;">
Puxa champs, você quase conseguiu reproduzir a filosofia Java... aumentou consideravelmente a complexidade de leitura do código e a quantidade de linha e ainda consegui o pior desempenho :)<br><br>Voltando ao post da Paty, eu ainda não entendi qual é o milagre/lógica e/ou restrição de efetuar uma operação deste tipo sem ciclos/loops. Vimos diversos métodos implícitos ou não de efetuar o loop e dar o retorno, mas ainda não entendi a restrição do for no problema da Paty.
<br><br>Faz muito mais sentido saber o que é mais rápido, mas não este tipo de restrição, a menos que fosse algum tipo de competição. Paty você poderia me explicar o motivo da restrição.<br><br>Solli M. Honório<br></span>
</div><br></div><br>