eficiencia de numpy.array

[Reynaldo Baquerizo]

Algo de documentación podrías conseguirlo de MathWorks pues hay 
funciones bastantes similares a las de Matlab.

Pau Cervera Badia escribió:
> 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
>>
>>
>