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.