Related articles |
---|
IEEE 754 vs Fortran arithmetic robertsj@admin.ogi.edu (John Roberts) (1990-10-22) |
Re: IEEE 754 vs Fortran arithmetic burley@world.std.com (1990-10-24) |
Re: IEEE 754 vs Fortran arithmetic henry@zoo.toronto.edu (1990-10-24) |
Re: IEEE 754 vs Fortran arithmetic tim@ksr.com (Tim Peters) (1990-10-24) |
Re: IEEE 754 vs Fortran arithmetic dik@cwi.nl (1990-10-25) |
Re: IEEE 754 vs Fortran arithmetic wsb@eng.Sun.COM (1990-10-25) |
Re: IEEE 754 vs Fortran arithmetic eggert@twinsun.com (1990-10-25) |
Re: IEEE 754 vs Fortran arithmetic wsb@eng.Sun.COM (1990-10-25) |
Re: IEEE 754 vs Fortran arithmetic sjc@key.COM (1990-10-26) |
Re: IEEE 754 vs Fortran arithmetic diamond@tkov50.enet.dec.com (1990-10-15) |
Re: IEEE 754 vs Fortran arithmetic tim@ksr.com (Tim Peters) (1990-10-27) |
[2 later articles] |
Newsgroups: | comp.compilers,comp.lang.fortran |
From: | dik@cwi.nl (Dik T. Winter) |
Followup-To: | comp.compilers |
Keywords: | Fortran |
Organization: | CWI, Amsterdam |
References: | <9010230628.AA22160@admin.ogi.edu> <BURLEY.90Oct24025053@world.std.com> |
Date: | 25 Oct 90 00:16:59 GMT |
In article <BURLEY.90Oct24025053@world.std.com> 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
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.