Re: floating point comparison

[eggert@twinsun.com (Paul Eggert)]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> This is a matter of binding of the language you are using to IEEE.
> The set of IEEE operatoins contains no such uncertainty,
> and a decent binding of a high level language
> to IEEE (e.g. SANE from Apple) must avoid such uncertainties.

But SANE never really caught on, nor did LIA-1 (the ISO standard
with weaker goals along this line).  Current Ada, C, Fortran, etc.
programs must therefore cope with this ``binding uncertainty''.

Let me elaborate for a bit.

One of the goals for IEEE floating point was to have floating point
operations be bit-for-bit compatible across hosts.  The sloppinesses
of language bindings are blocking us from reaching this goal in
practice.  It's obvious why bindings are sloppy: this lets
implementations (particularly x86 implementations) achieve much
better performance.

For the vast majority of floating point applications, performance is
more important than bit-for-bit compatibility, so it's easy to see why
bit-for-bit compatibility has fallen by the wayside.

Java has tried to fix this problem by insisting on strict
IEEE double->double arithmetic, but unfortunately this is
impossible to implement efficiently on the x86 architecture.
I believe most x86 Java implementers just fudge things:
that is, they don't quite exactly conform to the Java/IEEE standard.

(In an earlier part of this thread, you said that it was possible
to do double->double IEEE arithmetic efficently on the x86,
but I read the results in your ex-grad-student's rounding paper,
and nice as they are, they still don't solve the problem.
With IEEE double destinations, you'd need a 108-bit fraction in your
long registers to avoid double-rounding problems, and the x86
long-double fraction is much smaller than that.)

We'll have to live with this problem for many, many years.
It's not going away soon.  So it's better to deal with it
than to wish it away with ``it's just a matter of binding''.