Cher journal, je dois te confesser que j'ai déclenché quelque chose dont j'ai un peu honte.
Tu te souviens bien sûr de Pythran, ce compilateur pour noyau scientifiques écrit en Python, et de ce petit détail d'implémentation qui veut que le compilateur commence par transformer les fonctions Python en fonctions C++ template (a.k.a. transformer du code Python en meta-programme C++ pour faire stylé voire pédant).
Un choix de design a été de faire en sorte que ces fonctions ne font plus référence à aucune partie la l'API C de Python. C'est du code C++ « normal ». Et voilà ce que ça a donné :-/
Un zozo a décidé qu'au lieu de générer un code appelable depuis Python, on peut utiliser le C++ intermédiaire depuis du code C++ classique. Comme ça on prototype en Python, puis hop, on lance la CLI qui va bien et on a le code de prod avec des perfs décentes et très peu de dépendances.
Un autre zozo a décidé que ce même code C++ pouvait être associé à swig pour générer… du code appelable depuis Java. Hop on prototype en Python puis on appelle du code natif depuis Java via JNI, tranquille.
Et le plus drôle, c'est que ce genre de monstre a vocation à aller en prod, le délire ne s'arrête jamais :-)
# bidouille
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0.
Fondamentalement il n'y a pas de mal à ça. C'est un detournemt de la fonction initiale peut-être que le résultat est imparfait. Mais pourquoi pas. Parfois le bidouillage est très bien pour de petits besoin.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: bidouille
Posté par Tom D . Évalué à 9.
Je pense que c'était ironique et que serge_sans_paille est très heureux de voir ces usages non-orthodoxes de pythran (il y a des indices: "perfs décentes et très peu de dépendances")
[^] # Re: bidouille
Posté par serge_sans_paille (site web personnel) . Évalué à 7.
C'est effectivement totalement (shellement?) ironique. J'avais laissé la porte ouverte pour faire ça, mais une petite porte. Et voilà que des gens s'engouffrent dedans avec enthousiasme.
Je jubile.
# Au passage : Pythran: Crossing the Python Frontier
Posté par freejeff . Évalué à 4.
Sur l'implémentation naïve de la fonction de Rosen publier dans le numéro de mars/avril de cise dans cet example de code :
ne serait-ce pas n=x.shape ?
Cela ne gêne pas vraiment la compréhension de l'article mais, j'ai buté dessus un petit moment avant d'envisager que cela soit une coquille …
[^] # Re: Au passage : Pythran: Crossing the Python Frontier
Posté par serge_sans_paille (site web personnel) . Évalué à 4.
complètement :-/ Tu remarqueras aussi le joli travail de l'éditeur qui a pas été fichu de faire le rendu correct des commandes laTeX (bon, j'aurais du mieux relire son pre print aussi hein)
[^] # Re: Au passage : Pythran: Crossing the Python Frontier
Posté par freejeff . Évalué à 2.
Lorsque je parle à ce genre de personnes, j'utilise l'extension texmaths pour OpenOffice et j'exporte en .doc.
L'extension te permet d'inclure les images en svg et MS le supporte. De ce fait il y a moins de problèmes …
Surtout que pour un article tel que celui-ci ou LibreOffice, c'est pareil …
si ce n'est pour l'inclusion de code, mais cette extension devrait bien s'en sortir.
# Dans le même genre, il y a Cannoli
Posté par Boiethios (site web personnel) . Évalué à 1.
https://github.com/joncatanio/cannoli
[^] # Dans le même genre, il y a d'autres plus ou moins aboutis
Posté par Oliver (site web personnel) . Évalué à 2. Dernière modification le 20 août 2018 à 23:28.
Quelques autres projets expérimentaux que j'avais noté dans un coin en 2017.
Python -> C++
C++ -> Python
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
# Liste des fonctions de numpy supportées
Posté par freejeff . Évalué à 4.
S'il faut choisir entre numba et pythran, je pense que le choix pour moi se fera sur le support du sous ensemble de numpy.
Celui de numba est extrêmement faible, ce qui rend le port de code que l'on a voulu par trop lent (donc on utilise plein d'outils numpy) extrêmement chiant.
Je ne trouve pas une page explicite qui liste les fonction numpy supportées, c'est dommage !
Par exemple serait il possible de compiler ce bout de code ?
En soit, je ne suis pas sur de gagner en perf, mais comme j'appelle ce code dans plein de filtres, je ne peux pas utiliser numba par exemple si je fais appel à cette fonction.
Personnellement mon intérêt réside dans ne pas avoir à vectoriser des boucles avec plein de conditions sur les indices d'un tableau …
La c'est la version 2D pour jouer mais ne 3D, ce n'est même pas la peine.
Et si je le fais en cython, alors j'ai perdu tout le monde … et je dois tout gérer !
Donc une solution ou je serais directement capable en lisant une page de choisir de réduire mes appels au sous ensemble supporté serait cool. C'est juste que sans la page du support, c'est assez difficile.
Après, c'est peut être mois que n'ai juste pas cherché où il faut, cela ne serait pas la première fois …
[^] # Re: Liste des fonctions de numpy supportées
Posté par serge_sans_paille (site web personnel) . Évalué à 4.
http://pythran.readthedocs.io/en/latest/SUPPORT.html
Tu y liras que
np.mgrid
n'est pas supporté. Je vais jouer avec ton bout de code, il est marrant. J'ai ouvert un ticket dessus pour garder une trace https://github.com/serge-sans-paille/pythran/issues/918[^] # Re: Liste des fonctions de numpy supportées
Posté par freejeff . Évalué à 5.
Pour le coup le remplacer ne coûte pas cher …
On peut remplacer :
python
x,y=np.mgrid[1:8,5:10]
par des fonctions supportées par pythran :
Et ce n'est pas beaucoup plus dur en 3D …
Par contre tu vois que le typage est fait en argument de np.ones, je ne sais pas si cela peut être pénible, mais comme tu sembles avoir implémenté le np.ones en pythran !
Accélérer cette fonction serait cool, elle est nécessaire pour traiter les bords de tous les filtres en analyse d'image, et même pour le calcul de gradient … Et pour rendre la paternité du bout de code, c'est du stackoverflow.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.