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),