serge_sans_paille a écrit 261 commentaires

Je ne trouve pas une page explicite qui liste les fonction numpy supportées, c'est dommage !

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

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.

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)

Mais mais… tu as raison, très amusant ce petit format :-)

Si tu lis bien le code std::make_index_sequence n'est pas utilisé, mais une version naïve est fournie.

Quant au plantage sous GCC, je le constate aussi, mais je l'attribuerai plutôt à une limitation de GCC :-)

J'aurais bien aimé, mais non, la raison étant que si on passe par une fonction template on aurait un truc du genre

template<class... Ts>
auto cats(Ts... args) -> decltype(([]() {
    struct _ {
        char const * strings[sizeof...(args)] = {args...};
        const std::array<unsigned, sizeof...(args)> sizes = make_sizes(args...);
  };
  return strcat_helper<_>();}()))

(parenthèsage non contractuel).

Dans ce cas le decltype dépend du type de retour de la lambda, ce qui rentre dans la catégorie lambda expression in unevaluated context et c'est interdit. Mais ça passe en c++14 il me semble (vu que le type de retour est inféré).

Ça s'appelle Boost.operators non ?

C'est pour supporter l'argument axis de numpy.argmin ou numpy.argmax dans pythran. Le commit complet, à peu près autour de la bonne ligne, est là :

https://github.com/serge-sans-paille/pythran/pull/803/files#diff-b20072554ff33a1cd786318f40ff0368R110
(attention, réponse demandant un peu de connaissance de l'API numpy)

Comme le paramètre d'entrée est une expression-tableau de dimension N (paramètre template), et qu'on veut calculer argmin en suivant l'axe axis (paramètre non connu à la compilation), il faut générer les N patrons de boucle possibles suivant la valeur de l'axe.

Petit exemple pour N = 3, on peut vouloir générer (cas du min qui est un peu plus simple, mais c'est l'idée)

// axis == 2
for(int i = 0; i < n; i++)
    for(int j = 0; j < m; ++j)
        for(int k = 0; k < p; ++k)
           out[j, k] = min(out[j, k], in[i, j, k]);

// axis == 1
for(int i = 0; i < n; i++)
    for(int j = 0; j < m; ++j)
        for(int k = 0; k < p; ++k)
           out[i, k] = min(out[i, k], in[i, j, k]);

// axis == 0
for(int i = 0; i < n; i++)
    for(int j = 0; j < m; ++j)
        for(int k = 0; k < p; ++k)
           out[i, j] = min(out[i, j], in[i, j, k]);

le code pointé plus haut génère ces différentes boucles quelque soit N, dans le cas de argmin, en gardant un typage correct.

Je ne sais pas si je suis clair :-/

La fonction template en question est marquée noinline, ceci explique cela :-)

de briller en societe

complètement !

On peut aussi voir ça comme un exercice de style, une sorte de jeu, ce qui est le cas de ce journal :-)

L(e seul) avantage du deuxième, c'est que tu peux augmenter le nombre d'éléments du switch à volonté, sans avoir à spawner les copier-coller :-)

Ou bien c'est pour bien ranger le code ?

C'est ça !

Merci à toi de partager quelques instants de ton quotidien avec nous, de démystifier l'activité de recherche et montrer à quoi « ça sert » puisque l'on vit dans un monde où la finalité semble importante à beaucoup :-/

Quelques questions ! Tu dis que ta communauté est en contact avec celle qui poussent des langages comme Julia. Concrètement, comment se passent vos échanges, sur quels types de questions vous penchez vous etc ? Êtes-vous en contact avec la communauté LLVM pour aller vers des transformations prouvées, faire évoluer l'IR etc ?

Et tu n'as pas parlé d'une partie qui me semble prendre de plus en plus de temps dans le monde académique : la recherche de financement. Est-ce parce que l'INRIA est protecteur de ce point de vue, parce que c'est une partie négligeable dans ton cas, autre ?

Encore merci pour l'effort de vulgarisation et de partage !

Et pour éviter les problèmes de genre, ont parle aussi d'une truelle !

Ou un Bizu :-)

Pour un rol portable et efficace, il y a : https://blog.regehr.org/archives/1063 !

cf https://godbolt.org/g/TQchFT

@freejef, pour Lille, je te laisse voir avec l'organisateur.

Un grand merci pour ce journal passionnant, mêlant passion, code et humanisme. Je ne sais pas trop comment exprimer ça mais il se dégage de ce journal un ton de calme sérénité admirable. Ça donne envie !

Oh, et merci de m'avoir fait découvrir le Principe de subsidiarité !

Si l'original prend 1s, le nouveau temps est de 0.76s. Ça prend moins de temps, ça va plus vite.

Si un modérateur passe dans le coin : il manque un s à scientifique dans le titre, et dans la note de bas de page numéro 1, il faut remplacer chines par chiens sinon c'est moins drôle.

Merci pour ton journal qui m'a motivé à ajouter le support Pythran pour ce paquet ! La PR débarquera sous peu :-)

lu dans le README

The efficiency of the pure NumPy/mpi4py solver has been enhanced using Cython for certain routines.

Donc triche :-) Ce n'est plus du Python mais un langage hybride…

Qu'est-ce qui compile le plus vite ? gperf + le compilateur C, ou le code en C++ ?

Aucune idée. Je driais gperf +C intuitivement.

Qu'est-ce que tu entends exactement par le fait que olaf est moins robuste ?

C'est un bonhomme de neige, alors il fond :-)

En vrai, cette fonction de hash a de forte chance de toujours donner des collisions, donc elle est pas assez générique (j'aurais du écrire générique plutôt que robuste)

Comme en en C ou en C++, sans surprises, d'après la doc http://llvm.org/docs/LangRef.html#lshr-instruction

If op2 is (statically or dynamically) equal to or larger than the number of bits in op1, the result is undefined.
Donc undefined behavior

Ce n'est pas monstrueux, c'est le comportement uniforme des types inductifs.

j'ai ri :-)