python & numpy: somme d'une tranche de tableau

J'ai 1 dimensions tableau numpy (array_) et une liste Python (list_).

Le code suivant fonctionne, mais est inefficace parce que les tranches impliquer une copie superflue (certainement pour Python, les listes, et je crois aussi pour les tableaux numpy?):

result = sum(array_[1:])
result = sum(list_[1:])

Ce qui est une bonne façon de réécrire?

OriginalL'auteur max | 2011-05-05

  1. 13

    Trancher un tableau numpy n'est pas faire une copie, comme il le fait dans le cas d'une liste.

    Comme un exemple de base:

    import numpy as np
x = np.arange(100)
y = x[1:5]
y[:] = 1000
print x[:10]

    Cela donne:

    [   0 1000 1000 1000 1000    5    6    7    8    9]

    Même si nous avons modifié les valeurs dans y, c'est juste un point de vue dans la même mémoire que x.

    De découpage d'un ndarray renvoie une vue et de ne pas dupliquer la mémoire.

    Cependant, il serait beaucoup plus efficace d'utiliser array_[1:].sum() plutôt que d'appeler python builtin sum sur un tableau numpy.

    Comme une comparaison rapide:

    In [28]: x = np.arange(10000)

In [29]: %timeit x.sum()
100000 loops, best of 3: 10.2 us per loop

In [30]: %timeit sum(x)
100 loops, best of 3: 4.01 ms per loop

    Edit:

    Dans le cas de la liste, si pour quelque raison vous ne voulez pas faire une copie, vous pouvez toujours utiliser itertools.islice. Au lieu de:

    result = sum(some_list[1:])

    que vous pouvez faire:

    result = sum(itertools.islice(some_list, 1, None))

    Dans la plupart des cas, c'est exagéré, cependant. Si vous faites affaire avec des listes assez long pour que la gestion de la mémoire est un enjeu majeur, alors vous ne devriez probablement pas être à l'aide d'une liste pour stocker vos valeurs. (Les listes ne sont pas conçus pour stocker des éléments de manière compacte dans la mémoire.)

    Aussi, vous ne voulez pas faire cela pour un tableau numpy. Simplement en faisant some_array[1:].sum() seront de plusieurs ordres de grandeur plus rapidement et ne pas utiliser tout plus de mémoire que islice.

    Il doit y avoir quelque chose de bizarre dans votre machine. Selon mes timings sum(x) est à seulement 5% à 10% plus lent que x.sum() (sur numpy 1.5.1). Merci
    Êtes-vous à l'aide de relativement grande (>1000 éléments) des tableaux? Avec court (~10 éléments) des tableaux, de la somme est à seulement quelques pour cent plus lent, mais au moment où vous vous levez >1000 éléments, c'est une question de quelques microsecondes vs millisecondes. J'ai l'exécuter sur 3 machines avec un matériel différent et différentes versions de python & numpy. Les moments différents, mais la mise à l'échelle les résultats sont similaires. Ils sont à la fois linéaire en temps des algorithmes, mais une itération à travers chaque élément d'un tableau numpy en python (qui est ce que la somme n') est beaucoup plus lent que d'une itération à travers chaque élément de la mémoire tampon dans C (qui est ce que numpy)
    Non, même taille que la vôtre. Je vais abuser de la réponse pour un certain temps pour montrer à mes horaires. Merci
    comment avez-vous appeler en ligne de commande timeit dans [29] et [30] à partir de l'intérieur de la coquille? Avez-vous démarrer un shell interne est exécuté?
    C'est l'un de IPython de la "magie" des fonctions. ipython.scipy.org/moin C'est juste plus pratique que de mettre plein timeit.timeit appel avec le programme d'installation, etc... Tout ce qu'il fait, est d'utiliser le code exécuté précédemment dans le shell interactif, comme le setup kwarg à timeit.timeit. Si vous n'utilisez pas déjà IPython, avoir un coup d'oeil! Il a beaucoup de petites fonctionnalités sympas et macros!

    OriginalL'auteur Joe Kington

  2. 8

    Mon premier instinct était le même que Joe kingston portant quand il s'agit de listes, mais j'ai vérifié, et sur ma machine au moins, islice est toujours plus lent!

    >>> timeit.timeit("sum(l[50:950])", "l = range(1000)", number=10000)
1.0398731231689453
>>> timeit.timeit("sum(islice(l, 50, 950))", "from itertools import islice; l = range(1000)", number=10000)
1.2317550182342529
>>> timeit.timeit("sum(l[50:950000])", "l = range(1000000)", number=10)
7.9020509719848633
>>> timeit.timeit("sum(islice(l, 50, 950000))", "from itertools import islice; l = range(1000000)", number=10)
8.4522969722747803

    J'ai essayé un custom_sum et a trouvé qu'il était plus rapide, mais pas de beaucoup:

    >>> setup = """
... def custom_sum(list, start, stop):
...     s = 0
...     for i in xrange(start, stop):
...         s += list[i]
...     return s
... 
... l = range(1000)
... """
>>> timeit.timeit("custom_sum(l, 50, 950)", setup, number=1000)
0.66767406463623047

    En outre, au plus grand nombre, c'est plus lent, et de loin!

    >>> setup = setup.replace("range(1000)", "range(1000000)")
>>> timeit.timeit("custom_sum(l, 50, 950000)", setup, number=10)
14.185815095901489

    Je ne pouvais pas penser à autre chose à tester. (Pensées, quelqu'un?)

    Eh bien, je n'étais pas prétendre que c'était plus rapide (il n'y a aucune raison qu'il serait). (Je suis surpris de voir comment beaucoup plus lent, il est, si...) j'ai été en prétendant qu'elle serait d'utiliser moins de mémoire, qu'il ne ferait pas une copie de la liste. Elle ne faire que des.
    désolé, j'ai supposé que tu parlais de la vitesse.
    Eh bien, en relisant mon post, il semble certainement de cette façon! Je voulais dire l'utilisation de la mémoire, mais ce n'était pas clair du tout dans ce que j'ai écrit. Je suis intrigué à quelle différence il y a... Curieusement, avec d'assez grands listes, il semble que islice devient plus rapide encore... Vous avez besoin d' ~1e7 éléments, cependant. J'imagine qu'à ce stade de l'attribution de nouveaux la mémoire devient un goulot d'étranglement. En tout cas ton post est certainement une comparaison intéressante!

    OriginalL'auteur senderle

  3. 3

    @Joe kingston portant (c'est temporaire réponse juste vous montrer mes horaires, je vais l'enlever dès):

    In []: x= arange(1e4)
In []: %timeit sum(x)
100000 loops, best of 3: 18.8 us per loop
In []: %timeit x.sum()
100000 loops, best of 3: 17.5 us per loop
In []: x= arange(1e5)
In []: %timeit sum(x)
10000 loops, best of 3: 165 us per loop
In []: %timeit x.sum()
10000 loops, best of 3: 158 us per loop
In []: x= arange(1e2)
In []: %timeit sum(x)
100000 loops, best of 3: 4.44 us per loop
In []: %timeit x.sum()
100000 loops, best of 3: 3.2 us per loop

    Aussi loin que mes numpy(1.5.1) source indique, sum(.) est juste un wrapper pour x.sum(.). Ainsi, avec de plus grandes entrées de temps d'exécution est le même (asymptotiquement) pour sum(.) et x.sum(.).

    Modifier: Cette réponse a été conçu pour être juste temporaire, mais en fait ça (et ses commentaires) peut en effet être utile à quelqu'un. Donc je vais laisser comme il est tout à l'heure, jusqu'à ce que quelqu'un de vraiment me demander de le supprimer.

    Je pense que l'OP du code et de Joe timings utiliser le haut- sum() plutôt que numpy.sum(). Ce n'est qu'un des pièges de l'utilisation from numpy import *.
    Oui, j'ai été à dessein de comparer python sum de numpy est sum. Je suppose que l'OP a fait référence à python sum, ainsi. (Il peut très bien ne pas avoir été...) je suis d'accord avec @Sven, ici... C'est exactement pourquoi from whatever import * est mauvais, et pourquoi il est particulièrement mauvaise dans le cas d'un espace grand comme numpy! 🙂
    Aha, OK cela fait (genre de) sens. Cependant, personnellement, je le sentais assez à l'aise de travailler avec IPython profil scipy, même si elle ombres pythons sum(.). (Et depuis Joe a l'aide de IPython ainsi, j'ai juste mal interprété les horaires). BTW, devrais-je supprimer cette réponse ou à laisser (avec des commentaires comme de plus amples explications, OP question)? Merci
    Eh, je pense qu'il clarifie un point que d'autres personnes pourraient être confondus. Je l'avais quitter si c'était moi... Votre appel, même si, bien sûr.
    numpy import * ombres all(), min(), max(), sum(), any(), abs() et round(). Le plus grand show-bouchons pour moi (même pour l'utilisation interactive) sont any() et all() -- le numpy versions ne fonctionnent pas avec le générateur d'expressions. (Je voudrais aussi suggérer de ne pas supprimer cette réponse.)

    OriginalL'auteur eat

  4. 0

    Je ne trouve pas x[1:].sum() significativement plus lent que x.sum(). Pour les listes sum(x) - x[0] est plus rapide que sum(x[1:])(environ 40% plus rapide OMM).

    OriginalL'auteur jtniehof