Xref: utzoo comp.compilers:1438 comp.lang.fortran:3999 Path: utzoo!attcan!uunet!ogicse!husc6!spdcc!esegue!compilers-sender From: dik@cwi.nl (Dik T. Winter) Newsgroups: comp.compilers,comp.lang.fortran Subject: Re: IEEE 754 vs Fortran arithmetic Keywords: Fortran Message-ID: <2408@charon.cwi.nl> Date: 25 Oct 90 00:16:59 GMT References: <9010230628.AA22160@admin.ogi.edu> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: dik@cwi.nl (Dik T. Winter) Followup-To: comp.compilers Organization: CWI, Amsterdam Lines: 55 Approved: compilers@esegue.segue.boston.ma.us In article burley@world.std.com (James C Burley) writes: About Fortran NINT and IEEE NINT. That is correct, but it only tells us that Fortran NINT does not map on IEEE NINT, so if you implement Fortran NINT you might do it exactly as the Fortran standard says using IEEE primitives. Further: > 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, but there is some issue > here even if I can't remember just what it is! In the Ada Numerics Working Groups in Europe and in the US/Canada there is also discussion going on about -0.0 and +0.0 (Ada does not distinguish them like Fortran). However, in a full implementation of IEEE including the recommendations the only way to distinguish -0.0 and +0.0 is by either calculating 1/X or by use of the copysign function. Both ways do not conflict with the languages (in Fortran and Ada calculating 1/X for X=zero is undefined or defined to trap, depending on parameters, the Fortran copysign function is undefined for a zero sign argument). As Henry Spencer notes, Kahan has good arguments for -0.0 and +0.0 (not too surprising as he was one of the leading forces behind IEEE 754). On the other hand in his use -0.0 stands for negative infinitiseminals and +0.0 for zero and positive infinitiseminals. In my opinion (and I am not the only one) it would have been better to have a single zero and two signed infinitiseminals. (And as an aside, there have been machines that had only representations for signed infinitiseminals but not for zero, still not such a very bad idea.) But that is taking us quite a bit from compilers. What is relevant with respect to compilers (or the run-time system writers, but must we distinguish?) is the following. And this is why the point came up in the Ada Numerics Working Groups. We are working on the standardization of elementary mathematical functions in Ada. The current status is that the basic package of functions like SINE, COSINE etc. is very near to standardization. One of the functions included is: ARCTAN(Y, X) which returns the arctangent of Y/X. (Fortran users will recognize the ATAN2 function.) The specification tells us that the result is the range from -PI to +PI (approximately). The problem is, what is the result of ARCTAN(Y, zero). Does it depend on the sign of zero? Offhand I do not know what the Fortran standard tells us. Summary: IEEE 754 does not constrain languages that refuse to distinguish the sign of zero, but it gets hairy if some mathematical functions are considered. And of course, if you want all possibilities Kahan wants the language needs to know about inifinities and NaNs. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl -- Send compilers articles to compilers@esegue.segue.boston.ma.us {ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.