"Sebastian Haase" <haase@msg.ucsf.edu> writes:
Hi Alexander, Thanks for your reply and yes, I would be very interested to see more of your "pretty print" code.
Sure, I'll send you the code. As it is for a matrix class it only handles up to (array-)rank 2 currently (and uses methods of the matrix class) but I don't think changing either of these should be too hard.
I am trying to put together all kinds of useful things to make python ( with numarray and scipy) a possible replacement for Matlab...
<grin> Been, there done that -- actually still doing it.
When I was faced with the choice between matlab and python for my numerical work, I decided that despite the convince matlab offered for many things (libraries, interactive environment) I couldn't face the its monstrosity as a programming language and thus opted for python.
These were the main areas were I found python/Numeric was lagging behind:
1. Numeric.dot was much too slow (factor 40-100 and more for large arrays) 2. Although Numeric's arrays are quite general and powerful, I found writing down simple matrix expressions (dot(transpose(X), dot(...))) and the visual clarity of the repr of the result less attractive than matlab's. 3. Library support (e.g. in some fields many academics tend to make matlab code corresponding to their articles available, which is very handy to quickly try something). 4. Matlab came with very good plotting capabilities, whereas python's support for plotting was quite poor when I started using it. 5. Matlab also had a pretty good interactive environment.
So far I've managed to come up with the following (sometimes partial) solutions for the above problems.
1. An optional fast dot product using blas (although I somehow still ended up spending a few days on it, all the real work was done by my supervisor Richard Everson -- I've submitted a patch that made it into Numeric 23 but I don't think numarray has an the option of a fast dot product yet, although I haven't checked). 2. A powerful matrix class (mostly finished; should transparently support Numeric as well as numarray (the latter is not fully there yet), unreleased). 3. A high-level matlab interface (pretty much ready to be released). 4. A convenient and high-level plotting library that supports multiple backends (currently only proper support for matlab as backend although I started working on/contemplating others (e.g. grace, gnuplot and chaco); unreleased) 5. IPython (kudos to Fernando!) + emacs + a few convenience functions for things like saving variables and redefining classes makes a darn nice environment once one got the hang of it (unfortunately it meant I had to write the emacs support for ipython, it's available on the ipython website).
Of course if anyone wants to lend a hand, he/she is more than welcome ;)
I am not hoping for a similarly big documentation and help system, but just
Why not? Nowadays pretty much all python code comes with pretty good docstrings and implementing something like 'lookfor' shouldn't be
Hi Alexander, Thanks for the code - I will look into it I just read a few lines of your MatrixFormatter class seeing the definition of __repr__. Here is a thought: Is it possible that I overload the __repr__ of float (that is: the buildin data type) !? When I use pyCrust it automatically "fills in" default arguments like, func(a=0.1000000000001) So, this probably does not call the sys.displayhook - so __repr__ itself would need to be changed. Do you know if that is possible ? (It would recursively fix all list and matrix display problems I had ...) Thanks again, Sebastian ----- Original Message ----- From: "Alexander Schmolck" <a.schmolck@gmx.net> To: "Sebastian Haase" <haase@msg.ucsf.edu> Cc: <numpy-discussion@lists.sourceforge.net> Sent: Friday, November 21, 2003 7:23 PM Subject: Re: [Numpy-discussion] Community Poll: numarray default underflow handling == "ignore" ? particularly
hard. Already looking up docs and jumping to code in ipython is quite convenient (e.g. ``some_func?``).
the fact that it's free ( doesn't need to connect to a "license server" every other minute) and that it happily supports single-precision arrays ( not to mention memmap array !) should make it interesting.
And that it is not based on an abomination of a programming language but an excellent one, with plenty of high quality general purpose libs (and even if only doing numerics is concerned: Numeric/numarray's (APL-ish) design also doesn't compare badly to matlab, IMHO).
I know that I probably should use IPython,
Indeed, everyone should (from within emacs ;)
'as