[Numpy-discussion] MLab.py status: do you use it?
oliphant.travis at ieee.org
Tue Aug 28 15:09:30 CDT 2001
On Tue, 28 Aug 2001, Chris Barker wrote:
> Hi all,
> Paul recently requested help with testing and debugging MLab.py, and I
> offered to help out. He then sent me this note:
> "Paul F. Dubois" wrote:
> > MLab.py started out as a package that was supposed to give numpy a
> > Matlab look and feel. So useful questions are: are there really useful
> > things that should be added?
I use many of the functions in MLab regularly. I have no problem renaming it
to Utility.py or even incorporating it back into some other module.
scipy uses MLab currently has well.
> I can't answer these questions myself. Interestingly enough, despite the
> fact that I came to NumPy having used MATLAB heavily for five years (and
> one dissertation), I have made very little use of MLab.py. I'm wondering
> if anyone is, indeed, using it.
Yes, we are...
> As for trying to give numpy a MATLAB look and feel, I question the
> usefulness of that. NumPy looks and feels a little different than
> MATLAB, and, frankly, I like NumPy's feel better for the most part (now
> that rich comparisons have been added, anyway). The one thing that
> MATLAB has that NumPy doesn't, that I really miss, is list indexing.
> Having to use put and take is so much less elegant! I'm sure this isn't
> the least bit trivial to add, however. (is it even possible, given
> Python's idea of slicing?)
I don't think look and feel is the right word --- but increasing the number
of easily accesible utility routines is what the goal of SciPy is all about.
List indexing is difficult to add to the C-code due to the complexity of that
particular subroutine. Both Paul and I have looked at the code to try and
add this feature but neither one of us had the time to make it work right. I
think it would be possible if we could ever agree on what list-indexing
should do exactly for multidimensional arrays.
Python's idea of slicing is actually quite general. It takes
a[obj1, obj2, obj3] and essentially calls the (C-equivalent) of __getitem__
(the mapping interface) with the tuple (obj1, obj2, obj3). Any objects which
look like (3:10:2) are translated to a slice-object. So, the objects could
easily be indices into the array or a mask array of ones and zeros.
I seem to remember that there were some "difficult-to-decide" cases but I
can't recall them at the moment.
> Anyway, what I do think MATLAB does provide, and MLab.py should, is a
> whole bunch of utility functions for various common manipulations.
> > Do we really have what we have correct?
I'm pretty confident in it (that's not a life-staking claim...)
Most of my utility-development work is taking place in SciPy now. Bugs will
get fixed in MLab.py since Scipy uses it.
> > Most of all, these is no test routine for it. If you could make one
> > following the model of the test.py in directory Test, it would be great.
> > The idea is to have something that does not require the runner of the
> > test to know anything. It just runs silently unless something is wrong.
> I certainly could write up a test routine. I will start work on that. In
> the meantime, before I put too much effort into it, I'd really like some
> feedback on what people want MLab.py to be, if they see using it at all.
It's a good idea.
> As I said above, I'm not sure trying to give NumPy a MATLAB feel is a
> useful goal, so what is left is having all those handy functions.
> Perhaps we could shift away from MLab.py, and turn it into Utilities.py,
> which could use MATLAB (and other user experience) as guidance as to
> what utilities to include.
I've got some fun suggestions for utility functions which I've just been
storing away. Some of them are put into SciPy.
More information about the Numpy-discussion