verveer at embl.de
Sat Feb 5 09:43:52 CST 2005
I did not realize fully what matplotlib intents to do, so it seems I
picked a bad example, my apologies for that...
But I think your answers point out quite well that it may be worth to
go this route. Sure, people will need to adapt their packages, but it
will be worth it for all of us in the long run.
I do agree with your remarks about possible problems with having a
third incompatible package. But I think the goal would be to get that
package in the Python core, and to make actually sure that it is not
incompatible with numarray and scipy. I suppose when it does go into
the core, everybody will have to be compatible to some level.
On Feb 5, 2005, at 6:00 PM, John Hunter wrote:
>>>>>> "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
> numerix module.
> 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.
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
More information about the Numpy-discussion