RE: [Numpy-discussion] RE: Python 2.2 seriously crippled for numerical computation?

[Paul F D. <pa...@pf...>]

I also see the underflow problem on my Linux box 2.4.2-2. This is
certainly untenable. However, I am able to catch OverflowError in both
cases. I had a user complain about this just yesterday, so I think it is
a new behavior in Python 2.2 which I was just rolling out. A small
Fortran test problem did not exhibit the underflow bug, and caught the
overflow bug at COMPILE TIME (!).

There are two states for the IEEE underflow: one in which the hardware
sets it to zero, and the other in which the hardware signals the OS and
you can tell the OS to set it to zero. There is no standard for the
interface to this facility that I am aware of. (Usually I have had to
figure out how to make sure the underflow was handled in hardware
because the sheer cost of letting it turn into a system call was
prohibitive.) I speculate that on machines where the OS call is the
default that Python 2.2 is catching the signal when it should let it go
by.

I have not looked at this lately so something may have changed. 

You can use the kinds package that comes with Numeric to test 
for maximum and minimum exponents. kinds.default_float_kind.MAX_10_EXP
(equal to 308 on my Linux box, for example) tells you how big an
exponent a floating point number can have. MIN_10_EXP (-307 for me) is
also there.

Work around on your convergence test: instead of testing x**2 you might
test log10(x) vs. a constant or some expression involving
kinds.default_float_kind.MIN_10_EXP.

-----Original Message-----
From: num...@li...
[mailto:num...@li...] On Behalf Of Tim
Peters
Sent: Friday, March 01, 2002 9:43 PM
To: Huaiyu Zhu; num...@li...
Cc: pyt...@py...
Subject: [Numpy-discussion] RE: Python 2.2 seriously crippled for
numerical computation?


[Huaiyu Zhu]
> There appears to be a serious bug in Python 2.2 that severely limits 
> its usefulness for numerical computation:
>
> # Python 1.5.2 - 2.1
>
> >>> 1e200**2
> inf

A platform-dependent accident, there.

> >>> 1e-200**2
> 0.0
>
> # Python 2.2
>
> >>> 1e-200**2
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> OverflowError: (34, 'Numerical result out of range')

That one is surprising and definitely not intended:  it suggests your
platform libm is setting errno to ERANGE for pow(1e-200, 2.0), or that
your platform C headers define INFINITY but incorrectly, or that your
platform C headers define HUGE_VAL but incorrectly, or that your
platform C compiler generates bad code, or optimizes incorrectly, for
negating and/or comparing against its definition of HUGE_VAL or
INFINITY.  Python intends silent underflow to 0 in this case, and I
haven't heard of underflows raising OverflowError before.  Please file a
bug report with full details about which operating system, Python
version, compiler and C libraries you're using (then it's going to take
a wizard with access to all that stuff to trace into it and determine
the true cause).

> >>> 1e200**2
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> OverflowError: (34, 'Numerical result out of range')

That one is intended; see

http://sf.net/tracker/?group_id=5470&atid=105470&func=detail&aid=496104

for discussion.

> This produces the following serious effects: after hours of numerical 
> computation, just as the error is converging to zero, the whole thing 
> suddenly unravels.

It depends on how you write your code, of course.

> Note that try/except is completely useless for this purpose.

Ditto.  If your platform C lets you get away with it, you may still be
able to get an infinity out of 1e200 * 1e200.

> I hope this is unintended behavior

Half intended, half both unintended and never before reported.

> and that there is an easy fix.

Sorry, "no" to either.


_______________________________________________
Numpy-discussion mailing list Num...@li...
https://lists.sourceforge.net/lists/listinfo/numpy-discussion