jdhunter at ace.bsd.uchicago.edu
Sat Feb 5 09:11:21 CST 2005
>>>>> "Peter" == Peter Verveer <verveer at embl.de> writes:
Peter> BTW it was mentioned before that it would be a problem to
Peter> remove packages like LinearAlgebra and FFT from the core
Peter> Numeric. matplotlib was mentioned as an example of a
Peter> package that depends on them. I think that points however
Peter> to a fundamental problem with matplotlib: why does a
Peter> plotting library need FFTs and linear algebra? So I don't
Peter> think anybody can really argue that things like an FFT
Peter> should be in a core array package.
The dependence on fft arises from the original mission of matplotlib,
which was to provide a matlab compatible python plotting. matlab has
functions like psd, csd and cohere, which in addition to computing the
spectral density and coherence functions, generate the plots. So I
implemented Welch's Average Periodogram on top of fft to compute
spectral densities for these plotting commands.
I use Matrix a lot for matrix multiplications to do text rotations and
layout. If Matrix disappeared, it can be easily replace by wrapping
dot -- Todd did that already for the numarray equivalent in the
The matplotlib pylab module aspires to provide a matlab like
environment -- the focus is on plotting of course -- but as I've
needed things for my own work I've added commands to the
matplotlib.mlab module to provide matlab commands in python that do
require linear algebra, eg polyfit and polyval. Basically
matplotlib.mlab and matplotlib.pylab extend Numeric's MLab. This
section of the code could of course be folded into scipy.mlab,
Numeric.mlab, or wherever appropriate, but in my view it is already in
a pretty sensible place, in a module that attempts to provide a matlab
environment for python users.
If linear algebra, fft and random numbers disappeared from Numeric,
matplotlib would survive. As you say, they don't go to the core of
plotting. I could raise an exception if the user called psd and
didn't have scipy installed. And everyone else who has written code
based on the functionality of Numeric's extra modules could rewrite
their code as well. It would mean more work for me and less
functionality for some matplotlib users, but would be manageable.
We've put a fair amount of work in making Numeric and numarray work
transparently in matplotlib at the python and extension code level.
Having a third array package in the wild which is incompatible with
either is an unattractive option for me, but one which I can deal with
if need be. And if the goal is to get an array package into the
standard library that has the core functionality of Numeric and
numarray, and Numeric3 is the most sensible means to that end, then I
am all for it.
More information about the Numpy-discussion