Puisque tu parles de NumPy, j’imagine que tu veux parler du problème soulevé par son auteur. En clair, si tu écris une expression du genre c = a**2 + exp(b) avec a,b :: numpy.array, l’interpréteur va d’abord créer un objet pour a**2, puis un pour exp(b) et enfin sommer ces objets intermédiaires. Dans le même post sur son blog, l’auteur nous donne deux solutions qui se basent sur Cython ou Weave, en clair définir l’opération à effectuer dans un langage rapide et l’appeller depuis Python. On pourrait aussi rajouter la solution numexpr à la liste. Créer le code en C est effectivement la solution standard pour accélérer Python, en particulier pour réutiliser les bibliothèques existantes.
Pour illustrer la version Haskell, on peut regarder comment fait la bibliothèque repa. En reprennant la même expression, repa ne va pas créer des tableaux entiers intermédiares, mais seulement un tableau retardé qui indique que pour avoir les éléments du résultat exp(b) (en syntax NumPy), il faudra appliquer exp aux éléments de b. En gros, un tableau retardé c’est une fonction. Quand tu vas combiner a**2exp(b), tu vas encore une fois créer une nouvelle fonction qui va dire comment trouver les éléments de c (et qui en interne va utiliser a et b). En gros le vrai tableau n’est généré (de façon parallèle !) qu’au moment où tu en as besoin (en le forçant), en utilisant différentes astuces pour avoir un code (par exemple, si tu fais f(exp(b)), il va automatiquement combiner f et exp pour avoir un code optimal). Ça marche aussi de façon unifiée pour les changements de coordonnées (ça NumPy le fait un peu).
[^] # Re: un inconvénient des templates
Posté par neil . En réponse au journal Visiteurs en C++. Évalué à 5.
Puisque tu parles de NumPy, j’imagine que tu veux parler du problème soulevé par son auteur. En clair, si tu écris une expression du genre
c = a**2 + exp(b)aveca,b :: numpy.array, l’interpréteur va d’abord créer un objet poura**2, puis un pourexp(b)et enfin sommer ces objets intermédiaires. Dans le même post sur son blog, l’auteur nous donne deux solutions qui se basent sur Cython ou Weave, en clair définir l’opération à effectuer dans un langage rapide et l’appeller depuis Python. On pourrait aussi rajouter la solution numexpr à la liste. Créer le code en C est effectivement la solution standard pour accélérer Python, en particulier pour réutiliser les bibliothèques existantes.Pour illustrer la version Haskell, on peut regarder comment fait la bibliothèque repa. En reprennant la même expression, repa ne va pas créer des tableaux entiers intermédiares, mais seulement un tableau retardé qui indique que pour avoir les éléments du résultat
exp(b)(en syntax NumPy), il faudra appliquerexpaux éléments deb. En gros, un tableau retardé c’est une fonction. Quand tu vas combinera**2exp(b), tu vas encore une fois créer une nouvelle fonction qui va dire comment trouver les éléments dec(et qui en interne va utiliseraetb). En gros le vrai tableau n’est généré (de façon parallèle !) qu’au moment où tu en as besoin (en le forçant), en utilisant différentes astuces pour avoir un code (par exemple, si tu faisf(exp(b)), il va automatiquement combinerfetexppour avoir un code optimal). Ça marche aussi de façon unifiée pour les changements de coordonnées (ça NumPy le fait un peu).