Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!mipos3!omepd!pzbaum!jimv
From: jimv@pzbaum.uucp (Jim Valerio)
Newsgroups: comp.arch
Subject: Re: IEEE 754 vs. 854 (floating-point arithmetic)
Keywords: floating-point exceptions
Message-ID: <6@pzbaum.uucp>
Date: 28 May 89 18:13:06 GMT
References: <18721@cup.portal.com>
Reply-To: jimv@pzbaum.UUCP (Jim Valerio)
Organization: Perfecto Zissbaum, Portland Oregon
Lines: 28

In article <18721@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson)
asks some questions about exception handling under the IEEE 754 and IEEE 854
floating-point standards.

I am not aware of any application programs that care about how you handle
returning a default exception result for massive overflow or underflow.
I strongly recommend that IEEE trap handling be available to the application
program, because that is the only environment that has the contextual
knowledge to know whether the exception is fatal, can be worked around,
or can be ignored.

I believe that IEEE 854's permission to return an infinity or zero in the
case of massive overflow or underflow, rather than IEEE 754's QNaN, was an
attempt to correct a perceived mistake in the 754 exception handling.  If
you need to choose a result here, I recommend returning the infinity or
zero result, and not the QNaN.

I understand that there is a review of IEEE 754 coming up in the next few
years.  Personally, I'm looking forward to arguing for a number of modest
changes, including:
   (1)	Replace subnormal/denormal numbers by a single value (call it epsilon
	or infinitesimal), and define arithmetic underflow in terms of this
	limiting value.
   (2)	Remove bias adjusted results for trapped overflow and underflow, and
	always return either infinity or epsilon when overflow or underflow
	occurs.
-- 
Jim Valerio	jimv%pzbaum@omepd.intel.com, {omepd,reed,radix}!pzbaum!jimv