[Python-Dev] Function Hash: Check it in?

[Tim Peters]

[Paul Hughett]
> I would _guess_ that the IEEE 754 floating point standard does require
> that [6./3. == 2.],

It does, but 754 is silent on how languages may or may not *bind* to its
semantics.  The C99 std finally addresses that (15 years after 754), and
Java does too (albeit in a way Kahan despises), but that's about it for
"name brand" <wink> languages.

> ...
> If it doesn't, I may have to stop writing code that depends on
> the assumption that floating point computation is exact for exactly
> representable integers.  If so, then we're reasonably safe; there
> aren't many non-IEEE machines left these days.

I'm afraid you've got no guarantees even on a box with 100% conforming 754
hardware.  One of the last "mystery bugs" I helped tracked down at my
previous employer only showed up under Intel's C++ compiler.  It turned out
the compiler was looking for code of the form:

    double *a, *b, scale;
    for (i=0; i < n; ++i) {
        a[i] = b[i] / scale;
    }

and rewriting it as:

    double __temp = 1./scale;
    for (i=0; i < n; ++i) {
        a[i] = b[i] * __temp;
    }

for speed.  As time goes on, PC compilers are becoming more and more like
Cray's and KSR's in this respect:  float division is much more expensive
than float mult, and so variations of "so multiply by the reciprocal
instead" are hard for vendors to resist.  And, e.g., under 754 double rules,

   (17. * 123.) * (1./123.)

must *not* yield exactly 17.0 if done wholly in 754 double (but then 754
says nothing about how any language maps that string to 754 operations).

if-you-like-logic-chopping-you'll-love-arguing-stds<wink>-ly y'rs  - tim