[Python-es] eficiencia de numpy.array

[Pau Cervera Badia]

Ahora que habláis de esto, he conseguido usar numpy para calcular 
valores propios de matrices con el linalg, pero voy un poco a ciegas 
porqué no encuentro la documentación de forma fácil y me tengo que 
apañar con el help y lo que hay en la web de scipy. Sabéis de algo más 
user-friendly? (Soy muy novato en el numpy, un par de días.)

Gracias,

Y un poco off-topic: el linalg va bien para matrices sparse?

Chema Cortes wrote:
> 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 ;-)
> _______________________________________________
> Python-es mailing list
> Python-es en aditel.org
> http://listas.aditel.org/listinfo/python-es
>
>

-- 
Pau Cervera i Badia (e-mail cervera en ffn.ub.es)
{
   Departament de Física Fonamental               Martí i Franqués, 1
   Universitat de Barcelona                 Planta 3, despatx 346 bis
                                                      08028 Barcelona
   tel: +34 934 039 708                                         Spain

   "Simple things should be simple, complex things should be possible."
                                                            -- Alan Kay
   return http://www.ffn.ub.es/%7Ecervera/
}