Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: IEEE arithmetic (Goldberg paper)
Message-ID: <26665@as0c.sei.cmu.edu>
Date: 7 Jun 91 12:42:03 GMT
References: <9106070109.AA02137@ucbvax.Berkeley.EDU>
Reply-To: firth@sei.cmu.edu (Robert Firth)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 79

In article <9106070109.AA02137@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:

A couple of quick responses:

>    1. The question is not what fortran requires but what IEEE imple-
>mented in fortran requires.  One of the problems with IEEE's infs and
>NaNs is that they do not fit well with fortran.

Yes, that's the problem.  The Fortran standard describes the implementation
of arithmetic expressions in terms of the "mathematical" rules, that is,
the mathematical properties of real numbers.  It is the business of the
implementation to provide a reasonable approximation that, as far as
possible, obeys those rules.  If it fails to do so, i's not a legitimate
"fortran machine" and shouldn't claim to support ANSI F-77.

But a language implementation must follow the standard.  That is the
whole point of standards, after all, that they circumscribe the
permissible implementations.  You can't correct bogus hardware by
writing a bogus compiler.

>    3. In any case my reading of the standard is opposed to yours.
>Infinity is a possible value of x, 0*infinity does not have math-
>ematical value 0, therefore 0*x is not mathematically equivalent to 0
>in IEEE.

I would rather say that IEEE introduces bit patterns that are not valid
representations of real numbers, and then prescribes largely arbitrary
and improper semantics for the behaviour of those bit patterns. The
Fortran standard refers to the real numbers, not to bit patterns.

>        Do you replace 0*x with 0 when compiling without optimization?
>I think that if a (legal) program behaves differently when compiled with
>and without optimization that then the compiler is broken.  Perhaps you
>disagree.

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.

A ever, that's just my opinion; feel free to disagree or criticise.