[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4