From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 107079,c7637cfdf68e766 X-Google-Attributes: gid107079,public X-Google-Thread: f43e6,c7637cfdf68e766 X-Google-Attributes: gidf43e6,public X-Google-Thread: 109d8a,c7637cfdf68e766 X-Google-Attributes: gid109d8a,public X-Google-Thread: 103376,c7637cfdf68e766 X-Google-Attributes: gid103376,public X-Google-Thread: f8362,c7637cfdf68e766 X-Google-Attributes: gidf8362,public From: eggert@twinsun.com (Paul Eggert) Subject: Re: floating point comparison Date: 1997/08/30 Message-ID: <5u9dsv$brh$1@shade.twinsun.com>#1/1 X-Deja-AN: 269076945 References: <33E61497.33E2@pseserv3.fw.hac.com> <5sar4r$t7m$1@cnn.nas.nasa.gov> <5sbb90$qsc@redtail.cruzio.com> <33ECA115.13DE@math.okstate.edu> <5t5976$rle$1@ccioffe.ioffe.rssi.ru> Distribution: inet Organization: Twin Sun Inc, El Segundo, CA, USA Newsgroups: comp.lang.ada,sci.math.num-analysis,comp.software-eng,comp.theory,sci.math Date: 1997-08-30T00:00:00+00:00 List-Id: 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''.