[Numpy-discussion] RE: Python 2.2 seriously crippled for numerical computation?
Tim Peters
tim.one at comcast.net
Fri Mar 1 21:43:12 EST 2002
[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.
More information about the NumPy-Discussion
mailing list