From: Tim P. <ti...@co...> - 2002-03-02 05:42:56
|
[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. |