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

[Sebastian Haase]

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