IEEE 754

[Edward Jason Riedy]

And Tim Peters writes:
 - 
 - 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>.

After perusing some more of Python's code, I see.  sigh.

 - For starters, I know of no implementation of C99, so it's a bit premature to
 - switch to its features.  

Many of the library routines are already in GNU libc.  Some are also
available in vendor libcs, although with different include files
(ieeefp.h on Solaris).  The optimization pragmas aren't, but it may
be feasible to compile a few objects without optimization flags.  

And the Octave response to the xisnan problem I noted is that all
the platforms that sanely support NaN, Inf, etc. provide isnan and
family somewhere.  They just look for all the possible header files
and libraries.  If they're not found, they assume strange things
will happen with them anyways (like trapping on Alphas with old gccs).

It may not be as difficult as it seems

 - 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.

This type of thing could be generally useful.  Perhaps an 
implementation of the C99 spec with a suitable naming scheme 
would be warranted.  (Looks like the C99 spec is available 
from ANSI for $18.  Good.  More to add to the to-be-read pile.)

 - 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.

Moreso, it's possible to change many assumptions at runtime by
fiddling control words.  When Python is used as an interpreter
embedded in a larger app, this could be an important issue.  

 - I can do it for the intersection of x86 chips and Microsoft's compiler, 
 - but that's it.

Oof.  That's probably the worst intersection, too.  Stupid MS
compiler ``reduce the complexity of your expression'' bug...

I think I'm finally getting to that stage with current versions of
gcc and GNU libc, but there are so many older variations...  Plus,
I just noticed that the default for complex division in gcc frontends
is the overflow-unsafe method.  sigh.  More work to add to the to-be-
done pile.  gcc's a tad more difficult to modify than Python.

And Solaris + vendor libs doesn't seem too bad (with Sun's devel
package and sunmath.h).  T3E + Unicos likewise (has fenv.h, but also 
the flush-to-0 problem).  Need to check the SP + AIX, but I'd be 
shocked if it were too horrible, and I know who to ask if more's 
needed.  SGI + IRIX should be fine, but I don't have ready access.  
Don't know about Tru64, but the next gen of Alpha will have proper, 
fast gradual underflow support, so there's hope.

It seems the most difficult platform is the x86, and that's mostly
because there are just so many versions of OSes and libraries 
available.  And then there are non-IEEE platforms like IBM mainframes
(with Linux now, so `important') and VAXen.

 - The only platform-clever floating code in Python today is in
 - fpectlmodule.c, [...]

Evil.  The module's name made me hopeful.  Then I read it.  Evil.

 - 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

Some are being convinced.  Some (like the g77 maintainer) aren't.
I honestly cannot comprehend fighting against the only algebraically
complete FP arithmetic available...  I know it happens; I've been in
some of the arguments.  It's mind-blowing.

 - [...] but, alas, they - overwhelmingly don't ask for a better 754 
 - story).

Most of them don't know it exists.  I pretty much agree with Dr. Kahan
that it should be much more of a tool-builder issue than a tool-user 
one.  Like I said, I'd prefer if 99.999% of the users never had to
know the subtleties of the FP arithmetic in the background.  That 
means the tool builders (compilers, interpreters, libraries) have to
emphasize correctness for largest reasonable number of cases over
speed for the typical cases.  Users shouldn't have to ask for it.

And quite a few users who _do_ know it exists have given up on wide-
spread support.  But they're the ones who are content with evil, nasty
code that bends over backwards to support every possible error in every
possible place.  Trying to read or, worse, modify, the code is horrible.
That's about as un-Python as I can imagine.

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

Yup.  Seriously, though, it seems that most people in favor of making
Python an important numerical platform are also pretty much in favor
of IEEE 754 support.  Seems we have an opportunity to get things right.  
;)

Next interesting discussion:  How to add radix-10, IEEE 854 support...

Jason