Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!ubitrex.mb.ca!dab
From: dab@ubitrex.mb.ca (Danny Boulet)
Newsgroups: comp.arch
Subject: Re: IEEE arithmetic (Goldberg paper)
Message-ID: <1991Jun7.213024.23702@ccu.umanitoba.ca>
Date: 7 Jun 91 21:30:24 GMT
References: <9106070109.AA02137@ucbvax.Berkeley.EDU> <26665@as0c.sei.cmu.edu>
Sender: news@ccu.umanitoba.ca
Organization: Ubitrex Corporation, Winnipeg, Manitoba, Canada
Lines: 81

In article <26665@as0c.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>In article <9106070109.AA02137@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:
>

	.
	.
	.

>Yes, I disagree.  The issue is the relevance of the difference.  Is a
>compiler broken because an optimised program runs faster?  That's a
>difference in behaviour, but you presumably think it an acceptable one.
>Likewise, if a program transformation is permitted by the standard, a
>compiler is entitled to apply that transformation; it is the responsibility
>of the programmer to be aware which transformations are legal and not
>assume any of them won't happen.
>
>>        IF (0.0*X .NE. 0.0)
>>        So how would you code this (detecting whether x inf or NaN)?
>
>At the correct level of abstraction.  At the Fortran level, the
>abstraction is that of the real numbers - as is made clear in the
>standard.  At that level, NaNs don't exist, so you can't look for
>them.
>
>If you are asking about the bit-level representation of numbers, it
>is necessary to go to the lower level of abstraction, the machine
>level.  I would write an Assembly code subroutine, call it something
>like
>
>	LOGICAL FUNCTION ISANAN(X)
>
>and comment it very, very carefully.  Perhaps like this
>
>	C On some machines, the representation of the Fortran
>	C real numbers includes bit patterns that have no
>	C valid interpretation as real numbers.  The IEEE
>	C representation is one such, for example.  These
>	C bit patterns are called 'NaN', "not-a-number".
>	C
>	C Some simple algorithms used in numerical programming
>	C will fail, giving bizarre and useless results, if any
>	C of the supplied REAL input parameters in fact holds a
>	C bit pattern that is NaN.
>	C
>	C To guard against this, the programmer must test whether
>	C a real variable holds a NaN.  The following function
>	C implements that test.  Note that the test requires EXACT
>	C KNOWLEDGE of the target representation of real numbers
>	C and the semantics of target machine operations.  The
>	C implementation is therefore not portable.

Assuming that your Fortran compiler isn't too clever, the following
detects a NaN:

	IF ( X .NE. X ) THEN
		PRINT *, 'X is a NaN'
	ENDIF

This takes advantage of the rule that says that NaNs are unordered.
Unfortunately, a clever Fortran compiler is strictly speaking (I think)
free to notice that "X .NE. X" is always false 'mathematically' and
apply the obvious optimization.

If you're willing to live with the risk that such an optimization might
be applied, you could probably come up with an equivalent trick for
Infs.  I'm not totally sure but this would probably work (there is
almost certainly an easier way but I don't have the IEEE spec handy):

	IF ( X .NE. X ) THEN
	    PRINT *, 'X is a NaN'
	ELSE
	    Z = { some expression that always yields a +Inf }
	    Y1 = Z + X	{ yields NaN if X is -Inf }
	    Y2 = Z - X	{ yields NaN if X is +Inf }
	    IF ( Y1 .NE. Y1 .OR. Y2 .NE. Y2 ) THEN
		PRINT *,'X is an Inf'
	    ENDIF
	ENDIF

All bets are off if the target machine isn't IEEE or if the compiler
is too smart for your own good!  Isn't writing portable code fun!!