eficiencia de numpy.array

[Chema Cortes]

El 8/03/07, Francesc Altet <faltet en carabos.com> escribió:
> El dj 08 de 03 del 2007 a les 15:16 +0100, en/na Chema Cortes va
> escriure:
> > 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.

Totalmente de acuerdo, si por "calculista" se entiende lo que es un
"NumberCruncher". Que numpy se emplea en más ámbitos que las
matemáticas puras es clara muestra el que estamos hablándolo ahora
mismo dos físicos :-D


> 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.

Aún así, desde que descubrí las "tablas" del lua no quiero otra cosa.
Me gustaría que mucho que python tuviera ese grado de simpleza y toque
"minimalista" que tiene lua; pero, en cambio, sólo veo interfaces cada
vez más y más complejos, sin comprender con claridad las ventajas que
puedan proporcionar.


> 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'.

No he visto cómo hacer estos contenedores heterogéneos. ¿Puedes poner
algún ejemplo? (por ejemplo, mezclar float y complex).

> > 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:
>
> 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

En realidad, sólo se introdujo el "interface" de los slices. A parte
de numpy, sólo está implementado en algún módulo que ahora no
recuerdo. Pero, por defecto, no se pueden usar como índices otra cosa
que números enteros. De hecho, en python 2.5 se ha tenido que
introducir un nuevo interface (__index__) que necesitaba numpy para
poder tener índices no enteros (eg: float).


> > 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.).

Muy interesante. Esperemos que no se demore tanto como el libro de numpy ;-)