Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!cwi.nl!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch
Subject: Re: IEEE arithmetic (Goldberg paper)
Message-ID: <3618@charon.cwi.nl>
Date: 2 Jun 91 09:11:40 GMT
References: <9106010224.AA28532@ucbvax.Berkeley.EDU>
Sender: news@cwi.nl
Organization: CWI, Amsterdam
Lines: 58

In article <9106010224.AA28532@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:
 >           I guess I was a bit obscure here.  On IBM hex systems when
 > floating overflow occurs the default behavior is for an error message
 > to be printed which includes a traceback pointing to the offending
 > instruction.  Execution then continues (with the max floating number as
 > a fixup) but will terminate if more than a small number (5?) of over-
 > flows occur.  I was under the impression that this was typical behavior
 > for pre-IEEE systems.  Is that not the case?
No, it was not.  Amongst the system I used I have seen:
1.	Replace overflown value by largest representable value without
	any notification.
2.	Immediately trap on overflow, do not continue.
3.	Replace overflown value by an infinity which traps when used.
And more strategies have probably been implemented.

 >           I consider this behavior much friendlier than typical IEEE
 > behavior which is to run to completion then output infs and nans (or
 > worse plausible but wrong numbers) with no indication of where the
 > error occurred.
IEEE allows the user to specify that overflow traps.  However, especially
on the RS6000, this leads to e terrific decrease in performance.  So
apparently it is not cheap to trap.

 >           It seems to me that the existence of infs in IEEE is in-
 > creasing the likelihood of obtaining plausible-looking garbage.
The likelyhood is increased if you, the user, does not want to trap.  But
it also leads to some nice properties.  I disagree with the default
behaviour of IEEE, but I agree with the possibilities.

 >           79 bits is clearly an absurd length for a floating point
 > format (the same is true of the 43 bit single extended format).  As well
 > being very awkward the extended lengths are too close in precision to
 > the unextended lengths.
Perhaps, but note that the IEEE requirements for extended precision are
minimal requrements, so you may provide more in your implementation.  That
all systems that do provide extended double precision do provide the exact
requirements might tell something.  Note also that if a system implements
both IEEE single and IEEE double precision that double precision can be
seen as extended single precision (and I indeed do not know a single system
that implements true extended single precision).

 >                          The rationale behind the extended formats:
 > providing extra precision for intermediate terms is ridiculous.  If the
 > added precision is available it should always be used otherwise it is
 > of little value (see various comments on hex format).
Providing extra precision for intermediate terms is *not* ridiculous.
Witness the maf instructions on the RS6000.  Witness also the many old
papers that use inner products calculated in extra precision.
The problems with hex format are the following:
1.	The wobbling precision must let you use the worst case for error
	estimates.
2.	This makes single precision much more useles than binary single
	precision is already.
Note also that Blaauw reportedly has said that were he to design FP again
he would not use hex.
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl