El día 6 de agosto de 2013 12:18, Daπid <davidmen...@gmail.com> escribió: > También depende de cuánto quieras invertir. > > > In [4]: l=np.random.random(3*10**6); L=list(l) > In [8]: i = int(10**5.8) > In [11]: j = 3*10**6-10 > In [26]: %timeit l[i+1:j+1]=l[j:i:-1] > 10 loops, best of 3: 23.4 ms per loop > > In [27]: %timeit L[i+1:j+1]=L[j:i:-1] > 1000000 loops, best of 3: 427 ns per loop > > In this case, the list clearly beats NumPy, pero: > > > def flipper(K): > ...: i=10**4 > ...: j=10**5 > ...: K[i+1:j+1]=K[j:i:-1] > ...: return K > > In [6]: %timeit flipper(l) # NumPy array > 1000 loops, best of 3: 311 us per loop > In [7]: %timeit flipper(L) # Lista > 100 loops, best of 3: 5.51 ms per loop > > y, si quieres exprimirlo al máximo: > > nflipper=numba.autojit(flipper) > > In [10]: %timeit nflipper(l) > 10000 loops, best of 3: 105 us per loop > > In [11]: %timeit nflipper(L) > 1 loops, best of 3: 5.52 ms per loop # La lista no se optimiza > > usando numba0.10.
Interesante caso usando numpy y numba. Pero el problema que veo es que la función flipper no debería tener fijados los parámetros de corte, lo que supongo que hará perder bastante eficacia al JIT de numba. Lo que no me explico es cómo mejora tanto numpy cuando se empaqueta la operación en una clausura. > > > David. > > 2013/8/6 Antonio Beamud Montero <antonio.bea...@gmail.com>: >> El 05/08/13 21:54, Chema Cortes escribió: >> >>> Últimamente, estoy realizando estudios sobre la eficiencia de >>> distintos códigos python. Mirando qué tipo de colección podía ser más >>> eficiente según qué tareas, me encuentro con el siguiente párrafo en >>> la documentación de ["deque"][1]: >>> >>> "Deques support thread-safe, memory efficient appends and pops from >>> either side of the deque with approximately the same O(1) performance >>> in either direction. >>> >>> Though list objects support similar operations, they are optimized for >>> fast fixed-length operations and incur O(n) memory movement costs for >>> pop(0) and insert(0, v) operations which change both the size and >>> position of the underlying data representation." >>> >>> He comprobado que, efectivamente, el costo de insertar elementos al >>> principio de una lista es mucho mayor que añadir elementos al final de >>> la lista (x10000). >>> >>> En estos momentos , necesito trabajar con listas de números muy largas >>> (> 10e6 elementos) para trocear en dos pedazos, invertir uno de ellos >>> y volverlos a empalmar (método "2-opt"). Una forma de expresarlo: >>> >>> L[i+1:j+1] = L[j:i:-1] con i+1<j >>> >>> que equivale a: >>> >>> L[:i] + L[j:i:-1] + L[j+1:] >>> >>> Esta última expresión, aunque más clara, es poco eficiente al tener >>> que crear una nueva lista partiendo de tres sublistas intermedias. >>> >>> Los elementos no cambian de valor y tampoco cambia el tamaño de la >>> lista. Parece que la "lista" es la estructura más eficiente para esta >>> tarea (por lo que cuenta la documentación) siempre que no se modifique >>> en tamaño. Pero me pregunto si hay algún modo de hacer este manejo más >>> eficiente, tal vez usando alguna otra estructura, en python o numpy, >>> que mejore estas tareas de corte y empalme. Intuyo que con "arrays" se >>> reducen las necesidades de memoria, pero en estos momentos, la memoria >>> es lo que menos me preocupa. Busco un método genérico que pueda valer >>> para cualquier otro tipo de datos (eg: lista de vectores). >>> >>> >> >> Yo me decanté por usar numpy para resolver este tipo de problemas, aunque >> mis listas eran un orden de magnitud más pequeñas, después de hacer varias >> pruebas, el uso de las listas para operaciones simples, es tanto o más >> eficiente usando listas de python que crear arrays en numpy (bueno >> dependiendo de la operación), pero yo necesitaba métodos como 'diff', >> 'where', etc.. que si que marcaban diferencias respecto a mis anteriores >> implementaciones. >> >> Estaré muy atento a las conclusiones que llegues :-) >> >> Un saludo. >> >> _______________________________________________ >> Python-es mailing list >> Python-es@python.org >> http://mail.python.org/mailman/listinfo/python-es >> FAQ: http://python-es-faq.wikidot.com/ > _______________________________________________ > Python-es mailing list > Python-es@python.org > http://mail.python.org/mailman/listinfo/python-es > FAQ: http://python-es-faq.wikidot.com/ -- Hyperreals *R "Quarks, bits y otras criaturas infinitesimales": http://ch3m4.org/blog Buscador Python Hispano: http://ch3m4.org/python-es _______________________________________________ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
