IEEE 754 (was RE: [long and fussy] But what do these operators _mean_?)

[Tim Peters]

[Edward Jason Riedy]
> Python doesn't provide reasonable ways to test for Inf or NaN.
>
> These are needed in new eigenvalue routines (the only known
> optimal ones).  Yes, I know, there are some non-IEEE architectures
> left, but they shouldn't be encouraged.  (Keep in mind that I'm at
> Berkeley; expect a strong IEEE-754 bias.)

More accurately, Python provides no ways at all to test for Inf or NaN.  If
it provided unreasonable ways, half the battle would be over <wink>.

[Thomas Wouters]
> Well, now that the C standard (C99) says *something* about the
> implementation of floating point numbers, we can expect some
> change in this.
> However, given that it took 10 years before Guido decided for an
> all-out move from K&R C to ANSI C, it's not likely to happen
> overnight ;)
>
> Tim can probably say more about this, though, as usual.

For starters, I know of no implementation of C99, so it's a bit premature to
switch to its features.  There's no portable way to provide 754 support via
current C (e.g., as Jason said in another msg, *many* compilers optimize "x
!= x" to 0 today when x is double or float; indeed, Python itself does
too!).

This means that just to start, we need to define an internal 754 C API, and
implement it via mounds of platform-#ifdef'ed trickery.  The practical
problem with this is that it requires people expert in both their platforms
(HW and compiler and libc) and 754 subtleties, and they're mighty rare.  I
can do it for the intersection of x86 chips and Microsoft's compiler, but
that's it.  The only platform-clever floating code in Python today is in
fpectlmodule.c, and was written by someone whose main interest in life
seemed to be to make 754 hardware act as if 754 had never happened (i.e., it
aims to raise a fatal error (not a Python exception!) on overflow, invalid
operation and "divide by 0").

So that's the technical battle.  The political battle is that most
number-crunchers in practice still don't understand why 754 is A Good Thing,
and in my experience fight it tooth & nail (yes, Kahan likes to pin the
blame on short-sighted vendors and their infernal benchmarks, but having
been on all sides of this game, I can assure you that vendors will claw each
other to death to provide what users *ask* for -- but, alas, they
overwhelmingly don't ask for a better 754 story).

In short, just business as usual in the wacky world of floating point
<wink>.

nevertheless-python-*could*-become-an-outstanding-754-platform-ly
    y'rs  - tim