[Numpy-discussion] Hello and my first patch

A. M. Archibald peridot.faceted at gmail.com
Thu Oct 5 14:46:48 CDT 2006


On 05/10/06, Greg Willden <gregwillden at gmail.com> wrote:

> That is a much better policy in my view.
>
> I (gently) encourage this group (Travis?) to make this the policy for
> Numpy/Scipy.
>
> From my view as a newbie to numpy/scipy/matplotlib it isn't clear where I
> should look for what functionality.  Matplotlib plots the spectrogram but it
> only supports two or three window functions.  Numpy supports 4 or 5 window
> functions and Scipy apparently supports more but Matplotlib doesn't support
> Scipy.  Of course this is a minor example and I could just write the window
> function myself and then use it in Matplotlib but I want to give back so
> that the project can grow.  I'd really like to be able to leave Matlab
> behind and encourage everyone else to do the same but there are still these
> annoyances that need to be worked out.

Unfortunately, that policy (put it in numpy if it doesn't make the
build dependencies any worse) makes it even harder for the user to
figure out what is where. Say I want a fast matrix product. Do I look
in numpy or scipy? It'll run faster if it uses a tuned BLAS, so it
ought to have external requirements, so I'd look in scipy, but maybe
there's a simple non-tuned implementation in numpy instead...

Frankly, I tend to prefer the other approach to solving all these
issues: distribute numpy, scipy, and matplotlib as one bundle. The
requirements for scipy are not particularly onerous, particularly if
it comes as part of your distribution. There are currently some
problems successfully finding optimized versions of LAPACK and BLAS,
but to me the benefits of bundling the packages together outweigh the
difficulties:

* routines and objects can be in the package in which they make the
most semantic sense, rather than the one with the correct external
dependencies (how is a user supposed to know whether convolution uses
an external library or not?)

* documentation can be cross-referenced between packages (so the
Matrix class can tell people to look in scipy.linalg for inverses, for
example)

* users can more easily find what's available rather than rewriting from scratch

* derived packages (ipython, IDEs, MATLAB-alikes) have many fewer
possibilities to support

I'm not arguing that the development processes need to be connected,
just that making the primary distributed object a package containing
all the components will make life easier for everyone involved.

A. M. Archibald




More information about the Numpy-discussion mailing list