Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!petsd!peora!jer
From: jer@peora.UUCP (J. Eric Roskos)
Newsgroups: net.arch
Subject: Floating Point Rounding
Message-ID: <1357@peora.UUCP>
Date: Mon, 22-Jul-85 12:19:57 EDT
Article-I.D.: peora.1357
Posted: Mon Jul 22 12:19:57 1985
Date-Received: Thu, 25-Jul-85 05:28:08 EDT
References: <36900010@ima.UUCP>
Organization: Perkin-Elmer SDC, Orlando, Fl.
Lines: 64
Keywords: Floating point arithmetic, number theory, Perkin-Elmer R* Rounding

> Third, the 360's floating point unit truncates results rather than rounding
> (again in the interest of speed) which is equivalent to keeping one less
> bit than if you rounded.

This is not really necessarily in the interests of speed.  As I explained
to one of the people in here privately (believing he was going to post a
summary), our 3200 series floating point unit does round on the low-order
bit.  It does this probabilistically.  Not being a number theorist, I can't
demonstrate that the underlying assumption of equal-distribution involved
is valid*, but basically, it works like this.

Whenever a computation is completed, there are some guard digits left over
whose values can't be copied to the destination register (that being the
nature of guard digits in the first place).  Now, if the most-significant
(hexadecimal) guard digit is 7 or less, no change in the non-guard digits
(hereafter called just the "mantissa") are performed; in essence, it
"rounds down".  If the most-significant guard digit is 9 or more, the
mantissa of the result is "rounded up" by adding 1 to the mantissa.

Furthermore, if the most-significant guard-digit is 8, and any other guard
digit is nonzero, the hardware still "rounds up" by adding 1.  (Intuitively,
this may seem wrong, but if you think carefully about real-numbers -- and
understanding real numbers does always require a certain "willing
suspension of disbelief" -- you'll see that it does make sense.)

So far, this is plain, ordinary rounding.  But now comes the problem.  If
the most-significant guard digit is 8, and all other guard digits are zero,
you have a dilemma.  If you always round down, the result will come out
"too small" (we're speaking here in terms of absolute values); if you
always round up, it will come out "too large".  So... if all other guard
digits are 0, the least significant bit of the low-order digit of the
mantissa is FORCED to 1.  The theory here is that there is an equal
probability that this low-order bit will previously have been a 1 or a zero
-- something that is much more probable, I believe, than the incorrect
high-order bit assumption mentioned earlier.  As a result, this R* rounding
will give a "More Accurate" rounding than the IBM rounding, according
to this reasoning.

However, very sadly, in the real world, "better" is not always good enough.
Since IBM does it another way, the less-accurate results have come to be so
ingrained in the scientific community that more accurate results often
cause an uproar: "you didn't get the results our IBM got, so your machine
is broken!" they exclaim.  As a result, R* rounding is not that popular,
eventhough there is a large body of theory behind it showing that it is
a "better" rounding scheme than the IBM approach.

The moral of this very long story is that sometimes it is well known that
certain floating point algorithms are better, but they can't be used, even
though they are efficient, because machines that use them would get in
trouble in the marketplace.  As the theoretical physicist Richard Feynman
puts it, "in the real world, innovation is very hard."  This is very true.

---------

*Note that this statement is largely a scientific-disclaimer: i.e., I am
not willing to state as fact a claim I can't prove, while making a semi-
rigorous explanation of a well-defined algorithm.  I do believe,
personally, that the assumption is valid; it's just that this belief is
opinion.
-- 
Shyy-Anzr:  J. Eric Roskos
UUCP:       ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
US Mail:    MS 795; Perkin-Elmer SDC;
	    2486 Sand Lake Road, Orlando, FL 32809-7642