Guido van Rossum added the comment: > > (1a) Perhaps it's better to only do this for Python 3.0, which has a > > smaller set of platforms to support. > > +1 > Does Python depend on a working, valid and non-broken IEEE 754 floating > point arithmetic? Could we state the Python's float type depends on > IEEE754-1985 conform 64bit double precision format. Developers for a > platform with no IEEE754 conform double must role their own floatobject > implementation.
No, traditionally Python has just used whatever C's double provides. There are some places that benefit from IEEE 754, but few that require it (dunno about optional extension modules). > > (2) Have you two (Christian and Noam) figured out yet why repr(1e5) is > > '1.0' on some platforms? If it's not byte order (and I no longer > > believe it is) what could it be? An uninitialized variable? It doesn't > > seem to vary with the processor, but it could vary with the C runtime or OS. > > I wasn't able to reproduce the problem on my work stations. Can you give > us more information about the computer with failing tests? CPU, OS, > Kernel, libc etc. So far I have only one box where it is broken (even after make clobber and ./configure). I cannot reproduce it with a debug build. It's an x86 Linux box running in mixed 64-32 bit mode. >From /etc/lsb-release: "Ubuntu 6.06 LTS" uname -a: Linux pythonic.corp.google.com 2.6.18.5-gg16-mixed64-32 #1 SMP Wed Oct 10 17:45:08 PDT 2007 x86_64 GNU/Linux gcc -v: gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) I'm afraid I'll have to debug this myself, but not today. > > (3) Detecting NaNs and infs in a platform-independent way is tricky, > > probably beyond you (I know it's beyond me). (Of course, producing > > standardized output for them and recognizing these as input is easy, and > > that should definitely be done.) > > In fact detecting NaNs and Infs is platform-independent is dead easy IFF > the platform has IEEE 754 support. A double uses 64bit to store the > data, 1 bit signum, 11 bit exponent and 53bit fraction part (aka > mantissa). When all bits of the exponent are set (0x7ff) the number is > either a NaN or +/-Inf. For Infs the fraction part has no bits set (0) > and the signum bit signals +Inf (sig: 0) or -Inf (sig: 1). If one to all > bits of the mantissa is set, it's a NaN. > > The form (normalized or denormalized) is regardless for the detection of > NaN and Inf. An autoconf macro can easily detect the endianness of the > double implementation. Only for IEEE 754 though. > We can also use the much slower version and check if x > DBL_MAX for > +Inf, x < -DBL_MAX for -Inf and x != x for NaN. Of course the latter isn't guaranteed to help for non-IEEE-754 platforms -- some platforms don't have NaNs at all! __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
