> > (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!