Efficacité calcul itératif

Après essais, ce n’est pas si efficace que ça (comme >0.). (Et ce n’est pas accepté par numba.)

C’est quand même étrange qu’on ne puisse pas accéder au bon bit de signe, non ? Ou alors les floats sont codés sans bit de signe ?

Après essais, ce n’est pas si efficace que ça (comme >0.)

Quoi donc, écrire __gt__ ? Si oui c’est normal, les deux sont compilés exactement de la même façon en bytecode…

C’est quand même étrange qu’on ne puisse pas accéder au bon bit de signe, non ?

Ben tu peux avec np.signbit, c’est juste que sur un seul flottant l'overhead de l’appel doit te plomber les perfs. De façon générale, mesurer les perfs de lignes de codes isolées en dehors des conditions réelles, ça sert à rien. Il faut profiler le code en conditions réelles.

En conditions réelles aussi np.signbit est plus lent, ou du moins pas plus rapide

Probablement parce que sur un seul flottant (ou un petit nombre), le coût du look up et de l’appel vient surpasser le gain fait sur la comparaison elle même. Si tu appelles signbit sur un tableau de 100 flottants, tu as un petit gain, et ce gain augmente avec la taille du tableau :

% python3 -m timeit -s "import numpy as np" "np.signbit(np.zeros(100))"
500000 loops, best of 5: 939 nsec per loop
% python3 -m timeit -s "import numpy as np" "np.zeros(100)>0."
200000 loops, best of 5: 1.13 usec per loop

EDIT : ah non, après quelque tests sur des tailles différentes, toute la différence est dans le bruit de la mesure.

Mmh, je veux bien croire que sur de grands tableaux on y gagne. Mais je fais comment avec un scalaire pour avoir un coût d’appel plus faible ?

Je parle bien de quelque chose en conditions réelles, où je dois contrôler rapidement le signe

Je suis très dubitatif sur le fait que c’est ce qui est bloquant dans ton application, mais si c’est le cas c’est le signe (hehe) que tu as atteint les limites des services que peut te rendre Python, ou du moins son implémentation classique. Tu peux tenter par exemple de coder un morceau en Fortran comme discuté par @Gabbro un peu plus haut.

Perso, je fais pas du tout de code purement calculatoires en Python si les perf sont critiques à ce point. C’est souvent plus simple d’écrire en Fortran directement que profiler et recoder les morceaux critiques en Python, sauf à vraiment avoir un usage intensif des abstractions offertes par numpy et Python.