[Numpy-discussion] Numeric3

[Travis Oliphant]

>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.  
>  
>
Matlab-like environment is very much what scipy has always tried to be. 

>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.
>  
>
But MATLAB is a huge package.  SciPy has been trying to do the same 
thing.  Plotting was needed and matplotlib did a great thing in 
providing excellent plotting.  I've never understood the reason for 
matplotlib to remain separate except as evidence of the great schism 
that was occuring in the community.

In fact, when Eric and I began scipy, I wanted to call it pylab (you'll 
notice I have the pylab.sourceforge.net site).  I have fond ties to 
MATLAB myself.    Eric chose the scipy name which is probably better.  
So, it is very concerning to me to see matplotlib try to become what 
scipy is already trying to become.   I think it is very confusing to 
newcomers.

>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.
>  
>
Again,  from my perspective once Numeric3 is working reasonably well, 
Numeric ceases to exist for me.  Yes others may continue to download it, 
but I won't be maintaining it anymore.

-Travis