eficiencia de numpy.array

[Francesc Altet]

El dj 08 de 03 del 2007 a les 15:16 +0100, en/na Chema Cortes va
escriure:
> El 8/03/07, tny <a.porrua en gmail.com> escribió:
> 
> > Pues tengo entre manos muchas operaciones matemáticas, y con listas de
> > un buen tamaño, pero no son operaciones como sum que pueda realizar la
> > propia lista, y la memoria que ocupe no es, en este caso, importante así
> > que me voy a decantar por las listas de python.
> 
> Resulta extraño que preguntes sobre "eficiencia", para que luego digas
> que no vas a tener problemas con lo que ocupe la lista :-P
> 
> De todos modos, el numpy está pensado por y para matemáticos. Aunque
> no sea por "efectividad", deberías mirarlo desde el punto de vista
> matemático.

Bueno, no estoy de acuerdo con eso de que numpy esté por y para
matemáticos, al menos en el sentido 'estricto' de matemático. Yo como
máximo diría que está hecho por 'calculistas' para 'calculistas'. Y sin
embargo, con esta última afirmación tampoco estaria haciendo del todo
justicia a NumPy.

Aparte de los calculistas, numpy brilla con luz propia en otros aspectos
como por ejemplo como contenedores de datos complejos (que a posteriori
pueden ser usados en 'cálculos' tradicionales o no) con mucha eficiencia
o el tema de hacer ordenaciones a velocidades de C y con un consumo muy
eficiente de memoria. Cuando digo contenedores 'complejos' me refiero al
hecho de que numpy no sólo es capaz de almacenar arrays homogéneos
(todos los componentes son del mismo tipo), sino también heterogéneos
(los componentes pueden ser de tipos diferentes, tipo tabla SQL) e
incluso heterogéneos con varios niveles de anidamiento. Esto es algo que
ya se empezó a introducir en numarray pero que se ha integrado y
mejorado sustancialmente en NumPy. Todo esto hace de NumPy una libreria
de uso yo diria que básico en bastantes campos diferentes de los de
'calculismo'.

Por poner un ejemplo, uno muy importante puede ser el de las bases de
datos. De vez en cuando aparece gente en las listas preguntando por qué
los interfaces de python suelen ser tan lentos cuando hacen consultas a
bases de datos cuyo conjunto de resultados es muy grande. La respuesta
es precisamente que Python no puede crear contenedores complejos
(descarto pues el módulo array) para grandes cantidades de datos de una
manera rápida y eficiente. NumPy los tiene, como tiene también
capacidades óptimas de ordenación de dichos contenedores. Así pues,
seguramente en el futuro próximo veremos un acercamiento a NumPy por
parte de los programadores responsables de dichos interfaces para base
de datos. Hacerlo les puede suponer grandes ventajas y reducir, casi en
su totalidad, la brecha que existe entre las prestaciones que logran
actualmente (me refiero siempre al caso de resultados cantidades de
información) y las que se obtienen con programas hechos directamente en
C.

> Los arrays del numpy aceptan tuplas como índices
> multidimensionales, así como el rebanado "extendido" ("extended
> slice"). Como ejemplo del primer caso (índices multidimensionales), una forma
> rápida de obtener todos los elementos de un array mayores de 100:
> 
> a[a>100]
> 
> (con 'a>100' se obtiene un array de booleanos)
> 
> Como ejemplo de slicing extendiddo, si tienes una matriz
> n-dimensional, sumar una columna a otra sería:
> 
> a[...,i]+=a[...,j]

Bueno, para ser exactos, habría que decir que Python implementa, desde
hace algunas versiones (2.3) el rebanado 'extendido', aunque sólo para
objetos unidimensionales, como se puede apreciar en:

http://www.python.org/doc/2.3.5/whatsnew/section-slices.html
 
> Pero hay mucho más, como el cálculo matricial, FFT, LinearAlgebra,...

Correcto. Pero también hay que decir que existe una corriente ahora
mismo dentro de la comunidad de NumPy de empezar a mover parte del
código que se puede considerar estrictamente 'calculista' fuera de NumPy
para meterlo en SciPy. De esta manera se conseguiria un paquete muy
compacto (NumPy) que hace relativamente pocas cosas pero que las hace
muy bien y que, *muy importante*, sea fácil de instalar, y la parte más
complicada y más de cálculo en el sentido científico ponerla en SciPy,
cuyo tamaño es mucho mayor y *bastante* más difícil de instalar,
sobretodo si quiere obtener soporte de cálculo de muy altas prestaciones
(BLAS, LAPACK, etc.).

Saludos,

-- 
Francesc Altet    |  Be careful about using the following code --
Carabos Coop. V.  |  I've only proven that it works, 
www.carabos.com   |  I haven't tested it. -- Donald Knuth

------------ próxima parte ------------
_______________________________________________
Python-es mailing list
Python-es en aditel.org
http://listas.aditel.org/listinfo/python-es