Xref: utzoo comp.compilers:1447 comp.lang.fortran:4009 Path: utzoo!attcan!uunet!cs.utexas.edu!yale!mintaka!spdcc!ima!esegue!compilers-sender From: sjc@key.COM (Steve Correll) Newsgroups: comp.compilers,comp.lang.fortran Subject: Re: IEEE 754 vs Fortran arithmetic Keywords: Fortran Message-ID: <2209@key.COM> Date: 26 Oct 90 05:32:17 GMT References: <9010230628.AA22160@admin.ogi.edu> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: sjc@key.COM (Steve Correll) Organization: Key Computer Labs, Fremont, CA Lines: 21 Approved: compilers@esegue.segue.boston.ma.us In article , burley@world.std.com (James C Burley) writes: > Also, Fortran specifically prohibits zero from being negative (or being > significantly negative -- for example, I think, given that X is 0.0 and Y is > -0.0, IEEE 754 specifies that (Y.LT.X) whereas Fortran specifies that > (Y.EQ.X)). I might be wrong about the specifics... IEEE 754 says that -0 and +0 compare equal. However, IEEE 754 introduces a host of problems because of NaNs. Compilers which assume that .not.(x.gt.y) implies x.le.y, or that .not.(x.eq.y) implies x.ne.y may founder on the IEEE requirement that NaN compares unordered (false) with any other value. And the Fortran arithmetic IF is a particularly strange case, since NaN is neither less than, nor equal to, nor greater than zero. Thus IEEE technically requires three tests rather than two to implement this. -- sjc@key.com or ...{sun,pyramid}!pacbell!key!sjc Steve Correll [It is an interesting metaphysical problem to consider what an arithmetic IF should do when confronted with a NaN. Fall through? Ugh. -John] -- Send compilers articles to compilers@esegue.segue.boston.ma.us {ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.