Proposed standard python module: ieee754

[Tim Peters]

[Warnes, Gregory R]
> Not at all.  As it stands now, most common platforms have IEEE
> 754 compliant hardware, unfortunately, the C library routines are
> inconsistent in how and whether they deal with these special values.

[Martin v. Löwis]
> It's worse than that: The hardware is usually *not* (strictly) IEEE 754
> compliant, and even if it is, it is inconsistent across platforms in
> being so. IEEE supports different rounding modes and exception modes
> (this is probably wrong terminology), so whether computations give INF
> or an exception is vendor-defined (either is IEEE 754 compliant).

It's really not that lax:  a 754-conforming numeric environment must default
to round nearest/even, and with all traps disabled ("nostop" mode).  Not all
OS+C_runtime combos arrange to come up in that mode, and those that don't
aren't 754-conforming in the respects in which they deviate.  Python 2.3 has
grown some ugly platform-specific hacks to force nostop mode at Python
startup on at least one such system.  An irony is that if Python had a
serious 754 story, it would probably enable the divide-by-0, invalid
operation, and overflow traps by default.