Community Poll: numarray default underflow handling == "ignore" ?
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
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@noaa.gov
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@noaa.gov
------------------------------------------------------- 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@lists.sourceforge.net 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@stsci.edu> 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@stsci.edu> 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@lists.sourceforge.net 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:
On Fri, 2003-11-21 at 09:58, Alexander Schmolck wrote:
Todd Miller <jmiller@stsci.edu> 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@stsci.edu> 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
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@noaa.gov
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
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@physics.mcmaster.ca
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@physics.mcmaster.ca> To: "numpy-discussion" <numpy-discussion@lists.sourceforge.net> 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@physics.mcmaster.ca
------------------------------------------------------- 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@lists.sourceforge.net 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
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 == "ignore" underflow (vote for the change) Todd> 0 == don't care Todd> -1 == "warn" underflow (vote against the change) +1 Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D (Part 3 you find in my messages before fall 2003.)
"Sebastian Haase" <haase@msg.ucsf.edu> 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
"Sebastian Haase" <haase@msg.ucsf.edu> 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
(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
formating you desire (``if type(object) is float:...).
Since I am a heavy interactive user and found the default floating
of arrays somewhat clumsy for interactive work, I also wrote some more fanciful formatting code for my Numeric/numarray compatible matrix class
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@gmx.net> To: "Sebastian Haase" <haase@msg.ucsf.edu> Cc: <numpy-discussion@lists.sourceforge.net> Sent: Friday, November 21, 2003 4:37 PM Subject: Re: [Numpy-discussion] Community Poll: numarray default underflow handling == "ignore" ? point) list) formating 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
"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 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@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
"Sebastian Haase" <haase@msg.ucsf.edu> 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
+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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
participants (11)
-
Alexander Schmolck -
Chris Barker -
Colin J. Williams -
David M. Cooke -
Fernando Perez -
Jochen Küpper -
Jon Saenz -
Pearu Peterson -
Sebastian Haase -
Todd Miller -
Warren Focke