[SciPy-user] Arrayfns in numpy?

Fernando Perez fperez.net@gmail....
Wed Mar 7 01:53:25 CST 2007


On 3/6/07, Souheil Inati <souheil.inati@nyu.edu> wrote:
> -100
>
> I am strongly opposed to mixing computations into NumPY.  Why is 1-d
> interpolation good to have inside of NumPy? why not nd-interpolation?
> why not fft? or SVD? or some linear algebra thing?

We're already well past that point; ffts, svds and linear algebra are
all in there already, and won't be removed anytime soon:

In [1]: import numpy as N

In [2]: N.linalg?
Type:           module
Base Class:     <type 'module'>
Namespace:      Interactive
File:
/home/fperez/tmp/local/lib/python2.4/site-packages/numpy/linalg/__init__.py
Docstring:
    Core Linear Algebra Tools
    ===========

     Linear Algebra Basics:

       norm       --- Vector or matrix norm
       inv        --- Inverse of a square matrix
       solve      --- Solve a linear system of equations
       det        --- Determinant of a square matrix
       lstsq      --- Solve linear least-squares problem
       pinv       --- Pseudo-inverse (Moore-Penrose) using lstsq

     Eigenvalues and Decompositions:

       eig        --- Eigenvalues and vectors of a square matrix
       eigh       --- Eigenvalues and eigenvectors of a Hermitian matrix
       eigvals    --- Eigenvalues of a square matrix
       eigvalsh   --- Eigenvalues of a Hermitian matrix.
       svd        --- Singular value decomposition of a matrix
       cholesky   --- Cholesky decomposition of a matrix


In [3]: N.fft?
Type:           module
Base Class:     <type 'module'>
Namespace:      Interactive
File:
/home/fperez/tmp/local/lib/python2.4/site-packages/numpy/fft/__init__.py
Docstring:
    Core FFT routines
    ==================

     Standard FFTs

       fft
       ifft
       fft2
       ifft2
       fftn
       ifftn


etc...

Numpy is intended to be a reasonable replacement of all the
*functionality* of Numeric.  I think Travis tried very hard to make
sure that if an old code could run only on Numeric (without SciPy),
then it could also run on numpy (possibly after some manual work).

As much as I pushed for breaking all backwards compatibility for the
sake of *clean APIs* in numpy, I think it's a good decision to keep
b.compat. in terms of functionality.  Otherwise a number of projects
could be stuck on Numeric if for whatever reason they consider SciPy
too large/complex a dependency.

Cheers,


f


More information about the SciPy-user mailing list