Path: utzoo!utgpu!watmath!clyde!att!ucbvax!decwrl!sun!chiba!khb
From: khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering)
Newsgroups: comp.lang.fortran
Subject: Re: An exercise in futility
Keywords: Yale, Schlage, MasterLock, tumbler
Message-ID: <84866@sun.uucp>
Date: 11 Jan 89 18:07:28 GMT
References: <586@mbph.UUCP> <233@microsoft.UUCP>
Sender: news@sun.uucp
Reply-To: khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering)
Organization: Sun Microsystems, Mountain View
Lines: 45

In article <233@microsoft.UUCP> bobal@microsoft.UUCP (Bob Allison (uunet!microsoft!bobal)) writes:

>I thought that a previous note which indicated a possible reason why there 
>is no standard behavior for SQRT(-16.) was very good (e.g., IEEE lets 
>you specify whether you want an exception or a NaN).  Starting from there, 
>how can we develop a solution which is amenable to different floating point 
>methods which still attempts to provide portability?  Is such a feature 
>worth the cost?  Let's try to avoid polemics and attempt to formulate 
>some solutions instead of cursing the night.
>

Earlier drafts of f88 had exception handling as part of f88. This
COULD have been employed, but entailed enough complexity and
implementation issues that it was discarded for f88 (probably to
return in f99!).

For all ieee compliant machines there is standard conforming behavior.
NaN is what is returned; and exceptions can be
enabled in which case standard conforming behavior is to head for the
user defined exception handler.

Sun, HP, MIPS, Apollo, Multiflow, Convex and many others support this
important ancillary standard.

Consider the following code:

	print*,sqrt(-16.0)
	end

Produces (on a sun)

	NaN

Warning: the following IEEE floating point arithmetic
exception occured in this program and were never cleared:

	Invalid Operand;

While the f77 standard does not mandate this behavior, ieee floating
point standard for binary arithmetic does.



Keith H. Bierman
It's Not My Fault ---- I Voted for Bill & Opus