[Numpy-discussion] OT:pretty print of reals (was: Community Poll: numarray default underflow handling == "ignore" ?)

Sebastian Haase haase at msg.ucsf.edu
Mon Nov 24 11:12:05 CST 2003

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,
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,

----- Original Message ----- 
From: "Alexander Schmolck" <a.schmolck at gmx.net>
To: "Sebastian Haase" <haase at msg.ucsf.edu>
Cc: <numpy-discussion at lists.sourceforge.net>
Sent: Friday, November 21, 2003 7:23 PM
Subject: Re: [Numpy-discussion] Community Poll: numarray default underflow
handling == "ignore" ?

> "Sebastian Haase" <haase at msg.ucsf.edu> writes:
> > Hi Alexander,
> > Thanks for your reply  and yes, I would be very interested to see more
> > your "pretty print" code.
> Sure, I'll send you the code. As it is for a matrix class it only handles
> to (array-)rank 2 currently (and uses methods of the matrix class) but I
> 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
> 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
>    down simple matrix expressions (dot(transpose(X), dot(...))) and the
>    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
>    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
>    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
>    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
>    started working on/contemplating others (e.g. grace, gnuplot and
>    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
>    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
> Why not? Nowadays pretty much all python code comes with pretty good
> docstrings and implementing something like 'lookfor' shouldn't be
> 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
> > ( not to mention memmap array !)   should make it interesting.
> And that it is not based on an abomination of a programming language but
> excellent one, with plenty of high quality general purpose libs (and even
> 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

More information about the Numpy-discussion mailing list