c'est pas très élégant exécuter pleins de fonctions à la suite sur la séquence quand la parcourir une fois suffit
Ah, je pense que c'est un problème de culture et de définition de l'«élégance» :-) Classiquement, quand on utilise un langage de haut niveau, on est moins exigeant sur la performance brute. Je n'ai pas de culture algorithmique, et à mes yeux, quelque chose comme "amplitude <- max(x) - min(x)" est beaucoup plus élégant qu'une boucle qui ne fait qu'une passe : quelque part, on touche presque au langage naturel.
L'autre truc, c'est que quand on a un langage non compilé, on ne peut que deviner la manière dont les opérations sont optimisées, mais en faisant les tests, on peut avoir des surprises :
x <- rnorm(10000000)
> system.time(max(x)-min(x))
user system elapsed
0.128 0.000 0.132
> system.time(diff(range(x)))
user system elapsed
0.160 0.044 0.212
Visiblement, dans ce cas, il vaut mieux faire deux passes qu'une seule (je ne sais pas pourquoi, ça vient peut-être de l'implémentation en C des fonctions correspondantes).
[^] # Re: Pas bien intéressant...
Posté par arnaudus . En réponse au message exercices donnés au codinggame n°2. Évalué à 2.
Ah, je pense que c'est un problème de culture et de définition de l'«élégance» :-) Classiquement, quand on utilise un langage de haut niveau, on est moins exigeant sur la performance brute. Je n'ai pas de culture algorithmique, et à mes yeux, quelque chose comme "amplitude <- max(x) - min(x)" est beaucoup plus élégant qu'une boucle qui ne fait qu'une passe : quelque part, on touche presque au langage naturel.
L'autre truc, c'est que quand on a un langage non compilé, on ne peut que deviner la manière dont les opérations sont optimisées, mais en faisant les tests, on peut avoir des surprises :
Visiblement, dans ce cas, il vaut mieux faire deux passes qu'une seule (je ne sais pas pourquoi, ça vient peut-être de l'implémentation en C des fonctions correspondantes).