[Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)

[Tim Peters]

[Huaiyu Zhu]
> ...
> $ /usr/bin/python
> Python 1.5.2 (#1, Sep 17 1999, 20:15:36)  [GCC egcs-2.91.66 19990314/Linux
> (egcs- on linux-i386
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> from math import *
> >>> exp(777)
> inf
> >>> exp(-777)
> 0.0
> >>> sqrt(-1)
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> OverflowError: math range error
>
> This was sane behavior.  Are we saying that Python 2.0 has invented
> something better than IEEE 754?

754 allows users to choose the behaviors they want.  Any *fixed* policy is
not 754.  So long as we have to fix a single policy, yes, I believe Guido (&
know I) would say that raising OverflowError on exp(777), and silently
returning 0 on exp(-777), and raising ValueError on sqrt(-1) (*not*
OverflowError, as shown above), is indeed better than the 754 default
behaviors.  And 2.0 will do all three of those (& I just checked in the code
to make that happen).

About the sqrt example above, that's neither 754 behavior nor sane behavior:
default 754 behavior on sqrt(-1) is to return a NaN and keep on going.  I'm
pretty sure that's what glibc linked w/ -lieee actually does, too (if it
doesn't, glibc -lieee is violating 754).  That 1.5.2 raised an OverflowError
instead is insane, and appears purely due to an accident of how gcc compiles
code to compare Infs to NaNs (Python's mathmodule.c's CHECK() macro was
fooled by this into setting errno to ERANGE itself).  Python should raise a
ValueError there instead (corresponding to libm setting errno to EDOM --
this is a domain error, not a range error) -- which it does now under CVS
Python.

754-doesn't-work-unless-you've-got-all-of-it-ly y'rs  - tim