MLab.py status: do you use it?
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 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. 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?) 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?
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. 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'd really like folks' feedback on this before I put too much work into something no one uses, or will use. -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------
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.
Hi, this is surely a FAQ so I apologize in advance, but: I'm trying to install cephes-1.3 and getting this: cc -O2 -march=pentium -I/usr/local/include/python2.0 -I/usr/local/include/python2.0/Numeric -c amos_wrappers.c -o amos_wrappers.o In file included from cephes/mconf.h:162, from amos_wrappers.h:11, from amos_wrappers.c:8: cephes/protos.h:67: parse error before `sizeof' cephes/protos.h:68: parse error before `sizeof' cephes/protos.h:69: parse error before `sizeof' make: *** [amos_wrappers.o] Error 1 Am installing with: Python 2.0 (#14, Aug 2 2001, 10:06:36) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 and have already installed: Numeric-20.1.0 grateful for any help ... I did search a bit and it seems to be a known problem but I couldn't figure out the answer. Surely something simple. thanks Judah Judah Milgram milgram@cgpp.com P.O. Box 8376, Langley Park, MD 20787 (301) 422-4626 (-3047 fax)
I came across this problem a few months ago, I hacked the indicated lines in what seemed, at the time, to be the obvious fashion and the thing worked fine. I'm sorry that I can't be more helpful, but I haven't kept the file. The hack might just have been to comment out the offending statements. Bernie
I came across this problem a few months ago, I hacked the indicated lines in what seemed, at the time, to be the obvious fashion and the thing worked fine. I'm sorry that I can't be more helpful, but I haven't kept the file. The hack might just have been to comment out the offending statements.
Yes, I tried just that (also suggested by Travis Oliphant), and it compiled just fine. Thanks Judah Judah Milgram milgram@cgpp.com College Park Press http://www.cgpp.com P.O. Box 143, College Park MD, USA 20741 +001 (301) 422-4626 (422-3047 fax)
participants (4)
-
Bernard Frankpitt -
Chris Barker -
J. Milgram -
Travis Oliphant