Numpy Fonctions Pures pour la performance, la mise en cache

Je suis en train d'écrire quelques modérément critique pour les performances du code de numpy.
Ce code sera à l'intérieur de la plupart de boucle, d'un calcul que la course du temps est mesurée en heures.
Un rapide calcul suggèrent que ce code sera exécuté jusqu'à quelque chose comme 10^12 fois, dans certaines variantes du calcul.

Donc la fonction est de calculer sigmoïde(X) et une autre pour calculer sa dérivée (gradient).
Sigmoïde a la propriété que pour
y=sigmoïde(x), dy/dx= y(1-y)
En python pour numpy cela ressemble à:

sigmoid = vectorize(lambda(x): 1.0/(1.0+exp(-x)))
grad_sigmoid = vectorize(lambda (x): sigmoid(x)*(1-sigmoid(x)))

Comme on peut le voir, les deux fonctions sont de pures (sans effets secondaires),
donc, ils sont des candidats idéaux pour memoization,
au moins pour le court terme, j'ai quelques inquiétudes sur la mise en cache chaque appel à sigmoïde jamais fait: Stockage de 10^12 flotteurs qui prendrait plusieurs téra-octets de RAM.

Est-il un bon moyen d'optimiser ce?
Va python ramasser que ce sont des pures fonctions et les mettre en cache pour moi, comme il convient?
Suis-je à vous soucier de rien?

Notez que 1/(1+np.exp(-x)) accepte d'ores et déjà numpy des tableaux d'entrée et il est vraiment rapide (j'imagine memoization ne va pas aider du tout). En utilisant vectorize, vous êtes le rendant beaucoup plus lent, mais, depuis qu'il est mis en œuvre à l'aide de slow pour les boucles.
Quelle est la taille de x?
varie, mais j'ai pris pour ma règle de tumb calculs, x est le plus souvent un vecteur de longueur 100.

OriginalL'auteur Lyndon White | 2014-01-14

30

Ces fonctions existent déjà dans scipy. La fonction sigmoïde est disponible en scipy.spécial.expit.
```
In [36]: from scipy.special import expit
```
Comparer expit à la vectorisé fonction sigmoïde:
```
In [38]: x = np.linspace(-6, 6, 1001)

In [39]: %timeit y = sigmoid(x)
100 loops, best of 3: 2.4 ms per loop

In [40]: %timeit y = expit(x)
10000 loops, best of 3: 20.6 µs per loop
```
expit est également plus rapide que la mise en œuvre de la formule de vous-même:
```
In [41]: %timeit y = 1.0 / (1.0 + np.exp(-x))
10000 loops, best of 3: 27 µs per loop
```
Le CDF de la logistique de distribution est la fonction sigmoïde. Il est disponible en tant que cdf méthode de scipy.stats.logistic, mais cdf appelle éventuellement expit, donc il n'y a pas de point à l'aide de cette méthode. Vous pouvez utiliser le pdf méthode pour calculer la dérivée de la fonction sigmoïde, ou le _pdf méthode qui a moins de frais généraux, mais "rolling" est plus rapide:
```
In [44]: def sigmoid_grad(x):
   ....:     ex = np.exp(-x)
   ....:     y = ex / (1 + ex)**2
   ....:     return y
```
Timing (x est de longueur 1001):
```
In [45]: from scipy.stats import logistic

In [46]: %timeit y = logistic._pdf(x)
10000 loops, best of 3: 73.8 µs per loop

In [47]: %timeit y = sigmoid_grad(x)
10000 loops, best of 3: 29.7 µs per loop
```
Être prudent avec votre application si vous allez utiliser les valeurs qui sont loin dans la queue. La fonction exponentielle peut débordement assez facilement. logistic._cdf est un peu plus robuste que mon rapidité de mise en œuvre de sigmoid_grad:
```
In [60]: sigmoid_grad(-500)
/home/warren/anaconda/bin/ipython:3: RuntimeWarning: overflow encountered in double_scalars
  import sys
Out[60]: 0.0

In [61]: logistic._pdf(-500)
Out[61]: 7.1245764067412855e-218
```
Une mise en œuvre à l'aide de sech**2 (1/cosh**2) est un peu plus lent que le ci-dessus sigmoid_grad:
```
In [101]: def sigmoid_grad_sech2(x):
   .....:     y = (0.5 / np.cosh(0.5*x))**2
   .....:     return y
   .....: 

In [102]: %timeit y = sigmoid_grad_sech2(x)
10000 loops, best of 3: 34 µs per loop
```
Mais elle gère les queues de mieux:
```
In [103]: sigmoid_grad_sech2(-500)
Out[103]: 7.1245764067412855e-218

In [104]: sigmoid_grad_sech2(500)
Out[104]: 7.1245764067412855e-218
```
Quand vous avez dit que ", Vous pouvez utiliser le fichier pdf de la méthode pour calculer la dérivée de la fonction sigmoïde, ou le _pdf méthode qui a moins de frais généraux", ce qui n' surcharge signifie exactement? Êtes-vous ce qui suggère que la méthode protégée est plus rapide parce qu'il passe par moins de code?
Oui, ._pdf() a moins d'erreurs et de vérification des arguments. Il également ne pas utiliser le loc (emplacement) et scale paramètres de la distribution, de celles qui sont traitées dans le .pdf() méthode. .pdf() appelle éventuellement ._pdf() pour faire le calcul.

OriginalL'auteur Warren Weckesser
5

Juste élargissement sur mon commentaire, voici un comparatif entre votre sigmoïde par vectorize et l'utilisation de numpy directement:
```
In [1]: x = np.random.normal(size=10000)

In [2]: sigmoid = np.vectorize(lambda x: 1.0 / (1.0 + np.exp(-x)))

In [3]: %timeit sigmoid(x)
10 loops, best of 3: 63.3 ms per loop

In [4]: %timeit 1.0 / (1.0 + np.exp(-x))
1000 loops, best of 3: 250 us per loop
```
Comme vous pouvez le voir, pas seulement vectorize rendre beaucoup plus lent, le fait est que vous pouvez calculer 10000 sigmoids dans 250 microsecondes (qui est, de 25 nanosecondes pour chaque). Un seul dictionnaire de recherche en Python est plus lente que celle, sans parler de tous les autres code pour obtenir la memoization en place.

La seule façon d'optimiser, ce qui je pense est de l'écriture d'une sigmoïde ufunc pour numpy, qui, fondamentalement, permettra de mettre en œuvre l'opération dans C. de Cette façon, vous n'aurez pas à faire de chaque opération dans le sigmoïde à l'ensemble de la matrice, même si numpy est-ce réellement rapide.

Testé moi-même avec du code existant qui est de la formation d'un partenariat RBM: vectorisées: 1 boucles, best of 3: 5.44 s par boucle nonverctorised: 1 boucles, best of 3: 4.75 s par boucle nonVectorised avec une def au lieu d'un lambda: 1 boucles, best of 3: 4.53 s par boucle Pas très concret numéros temps il seulement une seule boucle, mais révélateur, je pense. Ainsi, un solide de vitesse pour un tel changement mineur.

OriginalL'auteur Gustav Larsson
1

Si vous êtes à la recherche d'memoize ce processus, j'avais envelopper ce code dans une fonction, et décorer avec des functools.lru_cache(maxsize=n). Expérience avec le maxsize valeur pour trouver la taille appropriée pour votre application. Pour de meilleurs résultats, utilisez un maxsize argument qui est une puissance de deux.
```
from functools import lru_cache

lru_cache(maxsize=8096)
def sigmoids(x):
    sigmoid = vectorize(lambda(x): 1.0/(1.0+exp(-x)))
    grad_sigmoid = vectorize(lambda (x): sigmoid(x)*(1-sigmoid(x)))
    return sigmoid, grad_sigmoid
```
Si vous êtes sur 2.7 (que j'attends de vous, puisque vous êtes à l'aide de numpy), vous pouvez prendre un coup d'oeil à https://pypi.python.org/pypi/repoze.lru/ pour un memoization de la bibliothèque avec la même syntaxe.

Vous pouvez l'installer via pip: pip install repoze.lru
```
from repoze.lru import lru_cache

lru_cache(maxsize=8096)
def sigmoids(x):
    sigmoid = vectorize(lambda(x): 1.0/(1.0+exp(-x)))
    grad_sigmoid = vectorize(lambda (x): sigmoid(x)*(1-sigmoid(x)))
    return sigmoid, grad_sigmoid
```
J'ajouterais que functools.lru_cache a été introduit en python 3.2 🙂
Bon appel -- j'ai ajouté dans un 2.7 alternative à ma réponse.

OriginalL'auteur Madison May

Surtout je suis d'accord avec Warren Weckesser et sa réponse ci-dessus.
Mais pour les dérivés du sigmoïde au suivant peut être utilisé:

In [002]: def sg(x):
     ...: s = scipy.special.expit(x)
     ...: return s * (1.0 - s)

Horaires:

In [003]: %timeit y = logistic._pdf(x)
10000 loops, best of 3: 45 µs per loop

In [004]: %timeit y = sg(x)
10000 loops, best of 3: 20.4 µs per loop

Le seul problème est la précision:

In [005]: sg(37)
Out[005]: 0.0

In [006]: logistic._pdf(37)
Out[006]: 8.5330476257440658e-17

OriginalL'auteur Sklavit

Vous devez vous connecter pour publier un commentaire.