Numerical Python

Todd Miller wrote:
> Someone recently suggested that we change the default for numarray
> underflow checking to "ignore".  Please  vote (+1, 0, -1):

What is it currently, and what other options are there?

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@...

+1

Jon Saenz.				| Tfno: +34 946012445
Depto. Fisica Aplicada II               | Fax:  +34 944648500
Facultad de Ciencias.   \\ Universidad del Pais Vasco \\
Apdo. 644   \\ 48080 - Bilbao  \\ SPAIN

On 20 Nov 2003, Todd Miller wrote:

> Someone recently suggested that we change the default for numarray
> underflow checking to "ignore".  Please  vote (+1, 0, -1):
>
> Todd
> --
> Todd Miller
> Space Telescope Science Institute
> 3700 San Martin Drive
> Baltimore MD, 21030
> (410) 338 - 4576
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

On Thu, 2003-11-20 at 18:18, Chris Barker wrote:
> Todd Miller wrote:
> > Someone recently suggested that we change the default for numarray
> > underflow checking to "ignore".  Please  vote (+1, 0, -1):
> 
> What is it currently, and what other options are there?

The default of underflow is "warn"

Other options are:  "ignore" or "raise"

> 
> -Chris
> 
> 
> -- 
> Christopher Barker, Ph.D.
> Oceanographer
>                                     		
> NOAA/OR&R/HAZMAT         (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
> 
> Chris.Barker@...
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576

On 21 Nov 2003, Todd Miller wrote:

> On Thu, 2003-11-20 at 18:18, Chris Barker wrote:
> > Todd Miller wrote:
> > > Someone recently suggested that we change the default for numarray
> > > underflow checking to "ignore".  Please  vote (+1, 0, -1):
> > 
> > What is it currently, and what other options are there?
> 
> The default of underflow is "warn"
> 
> Other options are:  "ignore" or "raise"

My votes:
warn: 0
ignore: 0
raise: -1

Pearu

Todd Miller <jmiller@...> writes:

> On Thu, 2003-11-20 at 18:18, Chris Barker wrote:
> > Todd Miller wrote:
> > > Someone recently suggested that we change the default for numarray
> > > underflow checking to "ignore".  Please  vote (+1, 0, -1):
> > 
> > What is it currently, and what other options are there?
> 
> The default of underflow is "warn"

I much prefer the current default. Having (potential errors) ignored silently
is IMHO against the spirit of python. What's the problem with manually setting
"ignore underflow" if and when one knows that underflows might occur but can
safely be ignored?

'as

On Fri, 2003-11-21 at 09:58, Alexander Schmolck wrote:
> Todd Miller <jmiller@...> writes:
> 
> > On Thu, 2003-11-20 at 18:18, Chris Barker wrote:
> > > Todd Miller wrote:
> > > > Someone recently suggested that we change the default for numarray
> > > > underflow checking to "ignore".  Please  vote (+1, 0, -1):
> > > 
> > > What is it currently, and what other options are there?
> > 
> > The default of underflow is "warn"
> 
> I much prefer the current default. Having (potential errors) ignored silently
> is IMHO against the spirit of python. What's the problem with manually setting
> "ignore underflow" if and when one knows that underflows might occur but can
> safely be ignored?

I'll read that as -1.  :-)

Todd

> 
> 'as
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576

Todd Miller wrote:
> > > Someone recently suggested that we change the default for numarray
> > > underflow checking to "ignore".  Please  vote (+1, 0, -1):

> The default of underflow is "warn"

assuming that ignore means that zero will be used, I vote +1

If the difference between zero and the smallest floating point number is
significant in your app, you'd better know what you're doing with
floating point, and you should then know to set the check to "warn" or
"raise".




-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@...

Chris Barker wrote:
> Todd Miller wrote:
> 
>>>>Someone recently suggested that we change the default for numarray
>>>>underflow checking to "ignore".  Please  vote (+1, 0, -1):
> 
> 
>>The default of underflow is "warn"
> 
> 
> assuming that ignore means that zero will be used, I vote +1
> 
> If the difference between zero and the smallest floating point number is
> significant in your app, you'd better know what you're doing with
> floating point, and you should then know to set the check to "warn" or
> "raise".

+1 also from me (also as Chris, assuming 'ignore' means replacing with zeros 
and not with NaNs).  Underflow is about the only case of errors where I think 
that silent ignore is a reasonable (if 'unpythonic') policy.

Cheers,

f

Todd Miller wrote:

>On Fri, 2003-11-21 at 09:58, Alexander Schmolck wrote:
>  
>
>>Todd Miller <jmiller@...> writes:
>>
>>    
>>
>>>On Thu, 2003-11-20 at 18:18, Chris Barker wrote:
>>>      
>>>
>>>>Todd Miller wrote:
>>>>        
>>>>
>>>>>Someone recently suggested that we change the default for numarray
>>>>>underflow checking to "ignore".  Please  vote (+1, 0, -1):
>>>>>          
>>>>>
>>>>What is it currently, and what other options are there?
>>>>        
>>>>
>>>The default of underflow is "warn"
>>>      
>>>
>>I much prefer the current default. Having (potential errors) ignored silently
>>is IMHO against the spirit of python. What's the problem with manually setting
>>"ignore underflow" if and when one knows that underflows might occur but can
>>safely be ignored?
>>    
>>
>
>I'll read that as -1.  :-)
>
This proposal leaves the control with the user, which seems to be the 
best way to go.

Colin W.

On Fri, 2003-11-21 at 12:20, Colin J. Williams wrote:
> 
> 
> Todd Miller wrote:
> 
> >On Fri, 2003-11-21 at 09:58, Alexander Schmolck wrote:
> >  
> >
> >>Todd Miller <jmiller@...> writes:
> >>
> >>    
> >>
> >>>On Thu, 2003-11-20 at 18:18, Chris Barker wrote:
> >>>      
> >>>
> >>>>Todd Miller wrote:
> >>>>        
> >>>>
> >>>>>Someone recently suggested that we change the default for numarray
> >>>>>underflow checking to "ignore".  Please  vote (+1, 0, -1):
> >>>>>          
> >>>>>
> >>>>What is it currently, and what other options are there?
> >>>>        
> >>>>
> >>>The default of underflow is "warn"
> >>>      
> >>>
> >>I much prefer the current default. Having (potential errors) ignored silently
> >>is IMHO against the spirit of python. What's the problem with manually setting
> >>"ignore underflow" if and when one knows that underflows might occur but can
> >>safely be ignored?
> >>    
> >>
> >
> >I'll read that as -1.  :-)
> >
> This proposal leaves the control with the user, which seems to be the 
> best way to go.

Just to be clear,  all we're talking about is the *default* handling of
underflow.  Regardless of what we decide,  underflow handling will be
configurable by the user on a per-thread basis as either: "ignore",
"warn", or "raise".

Todd

> Colin W.
> 
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576

On Fri, Nov 21, 2003 at 08:50:42AM -0800, Chris Barker wrote:
> Todd Miller wrote:
> > > > Someone recently suggested that we change the default for numarray
> > > > underflow checking to "ignore".  Please  vote (+1, 0, -1):
> 
> > The default of underflow is "warn"
> 
> assuming that ignore means that zero will be used, I vote +1
> 
> If the difference between zero and the smallest floating point number is
> significant in your app, you'd better know what you're doing with
> floating point, and you should then know to set the check to "warn" or
> "raise".

Agree, +1. It's quite common (for me) that I want exp(-1000) to give 0,
and not an error (or warning, espicially in a loop that goes for several
thousand iterations...) Overflow, yes, that's a problem, but not underflow.

(The behaviour below lead me to writing my own exp ufunc for Numeric:
>>> import Numeric
>>> Numeric.exp(-1000)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: math range error
>>> 
ugh.
)

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm@...

My vote would be '-1' ( if that means "I prefer ignore")
I'm thinking of an INTERACTIVE platform - and so it would just "look nicer"
without to many warnings.

Actually on that note: I read some time ago about pythons default for
printing floats:
>>> 0.1
0.10000000000000001
>>> print 0.1
0.1
>>> repr(0.1)
'0.10000000000000001'
>>> str(.1)
'0.1'

Does anyone here have an update on that ?
What I am especially interested in is when I have a list of (floating point)
(x,y) positions and
then typing in the var-name and getting all these ugly numbers is still very
frustration for me ;-)

Thanks,
Sebastian Haase


----- Original Message ----- 
From: "David M. Cooke" <cookedm@...>
To: "numpy-discussion" <numpy-discussion@...>
Sent: Friday, November 21, 2003 11:11 AM
Subject: Re: [Numpy-discussion] Community Poll: numarray default underflow
handling == "ignore" ?


> On Fri, Nov 21, 2003 at 08:50:42AM -0800, Chris Barker wrote:
> > Todd Miller wrote:
> > > > > Someone recently suggested that we change the default for numarray
> > > > > underflow checking to "ignore".  Please  vote (+1, 0, -1):
> >
> > > The default of underflow is "warn"
> >
> > assuming that ignore means that zero will be used, I vote +1
> >
> > If the difference between zero and the smallest floating point number is
> > significant in your app, you'd better know what you're doing with
> > floating point, and you should then know to set the check to "warn" or
> > "raise".
>
> Agree, +1. It's quite common (for me) that I want exp(-1000) to give 0,
> and not an error (or warning, espicially in a loop that goes for several
> thousand iterations...) Overflow, yes, that's a problem, but not
underflow.
>
> (The behaviour below lead me to writing my own exp ufunc for Numeric:
> >>> import Numeric
> >>> Numeric.exp(-1000)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> OverflowError: math range error
> >>>
> ugh.
> )
>
> -- 
> |>|\/|<
>
/--------------------------------------------------------------------------\
> |David M. Cooke
http://arbutus.physics.mcmaster.ca/dmc/
> |cookedm@...
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

On Fri, 2003-11-21 at 15:22, Sebastian Haase wrote:
> My vote would be '-1' ( if that means "I prefer ignore")

The vote is for switching from "warn" on underflow to "ignore" on
overflow, so:

+1 == "ignore" underflow   (vote for the change)
0  == don't care
-1 == "warn" underflow     (vote against the change)

-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576

"Sebastian Haase" <haase@...> writes:

> My vote would be '-1' ( if that means "I prefer ignore")
> I'm thinking of an INTERACTIVE platform - and so it would just "look nicer"
> without to many warnings.

Well, it's only a default so you could always deactivate it (for all
interactive sessions in your PYTHONSTARTUP if you wanted).

> 
> Actually on that note: I read some time ago about pythons default for
> printing floats:
> >>> 0.1
> 0.10000000000000001
> >>> print 0.1
> 0.1
> >>> repr(0.1)
> '0.10000000000000001'
> >>> str(.1)
> '0.1'
> 
> Does anyone here have an update on that ?



> What I am especially interested in is when I have a list of (floating point)
> (x,y) positions and
> then typing in the var-name and getting all these ugly numbers is still very
> frustration for me ;-)

You can customize python's interactive printing behavior any way you like (in
your PYTHONSTARTUP). Here is an example from my old ~/.pythonrc.py (nowadays I
almost exclusively use ipython).

import pprint
PRETTY_PRINT=1
_normal_displayhook = sys.displayhook
def _my_displayhook(object):
    if PRETTY_PRINT:
        # don't bore us with None
        if object is not None:
            pprint.pprint(object)
    else:
        _normal_displayhook(object)
sys.displayhook = _my_displayhook

You could add something to the above to achieve the floating point (or list)
formating you desire (``if type(object) is float:...).

Since I am a heavy interactive user and found the default floating formating
of arrays somewhat clumsy for interactive work, I also wrote some more
fanciful formatting code for my Numeric/numarray compatible matrix class that
amongst other things offers a number of formating options, including matlab
style. I found that this made my life much easier.

Thus:

>>> a
array([[-9.90000000e+01,  -9.72817182e+01,   0.00000000e+00,  -7.99144631e+01],
       [-4.54018500e+01,   4.84131591e+01,   3.03428793e+02,   9.96633158e+02],
       [2.88095799e+03,   8.00308393e+03,   2.19264658e+04,   5.97741417e+04]])
>>> m = matrix(a)
>>> m
matrix('''
1.0E+04 *

  -0.00990   -0.00973    0.00000   -0.00799
  -0.00454    0.00484    0.03034    0.09966
   0.28810    0.80031    2.19265    5.97741
''')
>>> m.show('long')
matrix('''
1.0E+04 *


Columns 0 through 3

  -0.009900000000000   -0.009728171817154    0.000000000000000
  -0.004540184996686    0.004841315910258    0.030342879349274
   0.288095798704173    0.800308392757538    2.192646579480672

Columns 3 through 4

  -0.007991446307681
   0.099663315842846
   5.977414171519782
''')
>>> m.show('+')
m.show('+')
matrix('''
-- -
-+++
++++
''')

etc.

Adapting this to e.g. format Numeric arrays similarly via the display hook
shouldn't be too hard, I can provide the code if you're interested.


'as

Hi Alexander,
Thanks for your reply  and yes, I would be very interested to see more of
your "pretty print" code.
I am trying to put together all kinds of useful things to make python ( with
numarray and scipy) a possible replacement for Matlab...
I am not hoping for a similarly big documentation and help system, but just
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.
I know that I probably should use IPython, but I also run python embedded in
a wxWindows app and therefore use pyCrust.

Thanks again,
Sebastian Haase


----- Original Message ----- 
From: "Alexander Schmolck" <a.schmolck@...>
To: "Sebastian Haase" <haase@...>
Cc: <numpy-discussion@...>
Sent: Friday, November 21, 2003 4:37 PM
Subject: Re: [Numpy-discussion] Community Poll: numarray default underflow
handling == "ignore" ?


> "Sebastian Haase" <haase@...> writes:
>
> > My vote would be '-1' ( if that means "I prefer ignore")
> > I'm thinking of an INTERACTIVE platform - and so it would just "look
nicer"
> > without to many warnings.
>
> Well, it's only a default so you could always deactivate it (for all
> interactive sessions in your PYTHONSTARTUP if you wanted).
>
> >
> > Actually on that note: I read some time ago about pythons default for
> > printing floats:
> > >>> 0.1
> > 0.10000000000000001
> > >>> print 0.1
> > 0.1
> > >>> repr(0.1)
> > '0.10000000000000001'
> > >>> str(.1)
> > '0.1'
> >
> > Does anyone here have an update on that ?
>
>
>
> > What I am especially interested in is when I have a list of (floating
point)
> > (x,y) positions and
> > then typing in the var-name and getting all these ugly numbers is still
very
> > frustration for me ;-)
>
> You can customize python's interactive printing behavior any way you like
(in
> your PYTHONSTARTUP). Here is an example from my old ~/.pythonrc.py
(nowadays I
> almost exclusively use ipython).
>
> import pprint
> PRETTY_PRINT=1
> _normal_displayhook = sys.displayhook
> def _my_displayhook(object):
>     if PRETTY_PRINT:
>         # don't bore us with None
>         if object is not None:
>             pprint.pprint(object)
>     else:
>         _normal_displayhook(object)
> sys.displayhook = _my_displayhook
>
> You could add something to the above to achieve the floating point (or
list)
> formating you desire (``if type(object) is float:...).
>
> Since I am a heavy interactive user and found the default floating
formating
> of arrays somewhat clumsy for interactive work, I also wrote some more
> fanciful formatting code for my Numeric/numarray compatible matrix class
that
> amongst other things offers a number of formating options, including
matlab
> style. I found that this made my life much easier.
>
> Thus:
>
> >>> a
> array([[-9.90000000e+01,  -9.72817182e+01,
 0.00000000e+00,  -7.99144631e+01],
>        [-4.54018500e+01,   4.84131591e+01,   3.03428793e+02,
9.96633158e+02],
>        [2.88095799e+03,   8.00308393e+03,   2.19264658e+04,
5.97741417e+04]])
> >>> m = matrix(a)
> >>> m
> matrix('''
> 1.0E+04 *
>
>   -0.00990   -0.00973    0.00000   -0.00799
>   -0.00454    0.00484    0.03034    0.09966
>    0.28810    0.80031    2.19265    5.97741
> ''')
> >>> m.show('long')
> matrix('''
> 1.0E+04 *
>
>
> Columns 0 through 3
>
>   -0.009900000000000   -0.009728171817154    0.000000000000000
>   -0.004540184996686    0.004841315910258    0.030342879349274
>    0.288095798704173    0.800308392757538    2.192646579480672
>
> Columns 3 through 4
>
>   -0.007991446307681
>    0.099663315842846
>    5.977414171519782
> ''')
> >>> m.show('+')
> m.show('+')
> matrix('''
> -- -
> -+++
> ++++
> ''')
>
> etc.
>
> Adapting this to e.g. format Numeric arrays similarly via the display hook
> shouldn't be too hard, I can provide the code if you're interested.
>
>
> 'as
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

+1

Warren Focke

On Thu, 20 Nov 2003, Todd Miller wrote:

> Someone recently suggested that we change the default for numarray
> underflow checking to "ignore".  Please  vote (+1, 0, -1):

"Sebastian Haase" <haase@...> 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

On 21 Nov 2003 15:26:32 -0500 Todd Miller wrote:

Todd> The vote is for switching from "warn" on underflow to "ignore"
Todd> on overflow, so:
         ^^^^
        under!

Todd> +1 =3D=3D "ignore" underflow   (vote for the change)
Todd> 0  =3D=3D don't care
Todd> -1 =3D=3D "warn" underflow     (vote against the change)

+1

Greetings,
Jochen
--=20
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert=E9, =C9galit=E9, Fraternit=E9                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 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,
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@...>
To: "Sebastian Haase" <haase@...>
Cc: <numpy-discussion@...>
Sent: Friday, November 21, 2003 7:23 PM
Subject: Re: [Numpy-discussion] Community Poll: numarray default underflow
handling == "ignore" ?


> "Sebastian Haase" <haase@...> 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
>
>

"Sebastian Haase" <haase@...> writes:

> 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) !?

Nope. You can't screw around with methods of builtins -- and this is a (quite
sensible) conscious design decision.

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

Nope, whatever pycrust uses needs to be changed (are you *sure* changing
sys.displayhook has no effect on pycrust (it might not change what it "fills
in", but what about actual output?) because that would seem sort of ...
suboptimal. Even so it shouldn't be too difficult to figure out how you can
customize printing in pycrust (by having a look at the pycrust code and/or
reading the manual or asking on the appropriate mailing-list).

> Do you know if that is possible ? (It would recursively fix all list and
> matrix display problems I had ...)

It wouldn't, it would just get you the float and list (tuple etc.) display you
want (arrays/matrices don't call repr on each individual array arguments to
compute their overall repr).


HTH,

'as