Message58443
> > (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! |
|
Date |
User |
Action |
Args |
2007-12-11 17:34:07 | gvanrossum | set | spambayes_score: 0.00323067 -> 0.0032306728 recipients:
+ gvanrossum, tim.peters, nascheme, christian.heimes, noam |
2007-12-11 17:34:06 | gvanrossum | link | issue1580 messages |
2007-12-11 17:34:06 | gvanrossum | create | |
|