Floating point problems

Florian Weimer fw at deneb.enyo.de
Thu Aug 31 01:39:30 EDT 2006


* David Roundy:

> definition of the variable and the comparison, this check may be
> failed.  The reason is that intermediate results are commonly stored

"commonly" = "on legacy i386 platforms"

> at higher than double precision, leading to non-IEEE arithmetic.

AFAIK, GCC's behavior is not in itself a contradiction to IEEE rules.

> It's sad, but we're stuck with it, as I'm not aware of any compiler
> that is capable of generating IEEE arithmetic.

It's more a language definition issue.  Ada, for instance, uses a
model based on interval arithmetic, and the usual i386 extended
precision arithmetic with occasional spilling still matches its
requirements:

 14. For any predefined relation on operands of a floating point type
     T, the implementation may deliver any value (i.e., either True or
     False) obtained by applying the (exact) mathematical comparison to
     values arbitrarily chosen from the respective operand intervals.

In addition, there are C compilers which are not affected by this
problem, even on the i386 architecture: Some of them use SSE2
arithmetic, some run the FPU in 64-bit mode (instead of 80-bit mode,
very common on Windows).  Or you can spill long doubles instead of
doubles where necessary, or spill-and-reload early so that there is no
observable difference (I believe Intel's compiler does one of these).


More information about the Glasgow-haskell-users mailing list