Re: [Numpy-discussion] MLab.py status: do you use it?

[Travis O. <oli...@ie...>]

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.