La solution de Ray est bonne. Cependant, sur ma machine, il est environ 2,5 fois plus rapide d'utiliser numpy.sum
à la place de numpy.min
:
In [13]: %timeit np.isnan(np.min(x))
1000 loops, best of 3: 244 us per loop
In [14]: %timeit np.isnan(np.sum(x))
10000 loops, best of 3: 97.3 us per loop
Contrairement à min
, sum
ne nécessite pas de branchement, ce qui, sur le matériel moderne, tend à être assez coûteux. C'est probablement la raison pour laquelle sum
est plus rapide.
éditer Le test ci-dessus a été effectué avec un seul NaN au milieu du tableau.
Il est intéressant de noter que min
est plus lente en présence de NaNs qu'en leur absence. Elle semble également plus lente lorsque les NaN se rapprochent du début du tableau. D'autre part, sum
semble constant, qu'il y ait ou non des NaN et quel que soit l'endroit où ils se trouvent :
In [40]: x = np.random.rand(100000)
In [41]: %timeit np.isnan(np.min(x))
10000 loops, best of 3: 153 us per loop
In [42]: %timeit np.isnan(np.sum(x))
10000 loops, best of 3: 95.9 us per loop
In [43]: x[50000] = np.nan
In [44]: %timeit np.isnan(np.min(x))
1000 loops, best of 3: 239 us per loop
In [45]: %timeit np.isnan(np.sum(x))
10000 loops, best of 3: 95.8 us per loop
In [46]: x[0] = np.nan
In [47]: %timeit np.isnan(np.min(x))
1000 loops, best of 3: 326 us per loop
In [48]: %timeit np.isnan(np.sum(x))
10000 loops, best of 3: 95.9 us per loop
0 votes
La validation de l'entrée de l'utilisateur ne fonctionne-t-elle pas dans ce scénario ? Comme dans le cas d'une vérification de NaN avant l'insertion.
0 votes
@Woot4Moo : non, la bibliothèque prend les tableaux NumPy ou
scipy.sparse
en tant que données d'entrée.2 votes
Si vous faites cela souvent, j'ai entendu de bonnes choses à propos de Bottleneck ( pypi.python.org/pypi/Bottleneck )