Unfortunately I'm getting ready to leave for scipy'07, so I won't be
able to look at this.
But if I may make a small comment, in my view MPL should simply not
contain any numerics, period (beyond that needed for plotting
functions). I realize that it's convenient to have a layer of
numerical functionality directly in there, since you control the
library and that lets you have in there what you want, when you want
it, rather than waiting for numpy to catch up. IPython used to do the
same (IPython.numutils, which is where that stuff in mlab came from),
but I've completely stopped. IPython also had plotting
(IPython.Gnuplot*), and I also stopped that, now all IPython has is
the bare minimum needed to support MPL (-pylab), but no actual
plotting facilities of its own.
In the days of Numeric/numarray/numerix, I think mlab made a lot of
sense. But I would hope that now, any truly useful numerical
contributions should go into numpy (there's no confusion anymore), so
that we have a clear separation of responsibilities:
- numpy: base numerics
- scipy: bigger algorithms, some domain-specific functionality
- scikits: extensions to scipy, most of the domain-specific
functionality, staging area for scipy candidates.
- mpl: plotting
- ipython: interactive work (and distributed computing)
It used to be that scipy had plotting and interactive stuff, mpl had
numerics and interactive code (the little standalone GTK-threaded
interpreter), ipython had numerics and plotting, etc. We all had a
bit of each other's domain.
Moving forward, I think we should all make an effort to avoid that.
Scipy by and large has shed all of its old plotting and interactive
support, IPython carries it but I haven't touched that code in years
(and it will just stay there, it won't move to the new branches).
In that regard, I think in the long run having MPL carry a numerical
layer confuses its purpose. Unless you (a collective you, the MPL
developers) decide that MPL is really meant to be a complete numerical
system, but then you should change the description from the website,
which currently reads:
"matplotlib is a python 2D plotting library which produces publication
quality figures in a variety of hardcopy formats and interactive
environments across platforms."
I realize that this requires more work, since it means asking the
numpy team for inclusion of things you might like to have and waiting
for that to happen, rather than just doing it yourselves. That
coordination takes time, obviously, and that's a scarce resource for
all of us. But I honestly think that now that the
Numeric/Numarray/numerix mess is finally behind us, this should be an
opportunity for completing the 'separation of responsibilities'
effort. In the long run, I think it will help new users coming to
Python to better understand what is what, it will make for a
stronger/better Numpy, etc.
I know this isn't an easy problem, because you are balancing
matlab-compatibility, backwards compatibility, ease of development
workflow, etc. In the end, I trust your judgment, I just wanted to
mention this point of view in case you find it feasible.
Cheers,
f
···
On 8/12/07, Eric Firing <efiring@...229...> wrote:
mlab.py in svn has now been changed quite a bit:
1) It uses straight numpy.
2) In many but not all cases, I tried to simplify algorithms by using
numpy capabilities. I did some testing, but beware: there may be new bugs.
3) For functions with numpy equivalents I put in deprecation warnings,
with the intention that mlab be stripped down to things that are useful
and are not readily available in numpy.
4) I added some comments to docstrings.
5) I added a "demean" function that is like detrend_mean but takes an
axis argument. This ability to operate on a specified axis might be
added to other functions in mlab.
Please test the new version. Especially if there are functions that you
contributed to mlab (Fernando, I think you provided many of them),