Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site unc.unc.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!mcnc!unc!rentsch
From: rentsch@unc.UUCP (Tim Rentsch)
Newsgroups: net.arch
Subject: Random Rounding in Floating Point
Message-ID: <1068@unc.unc.UUCP>
Date: Sat, 1-Mar-86 23:11:55 EST
Article-I.D.: unc.1068
Posted: Sat Mar  1 23:11:55 1986
Date-Received: Mon, 3-Mar-86 01:35:14 EST
References: <11896@ucbvax.BERKELEY.EDU> <5100014@ccvaxa>
Reply-To: rentsch@unc.UUCP (Tim Rentsch)
Organization: CS Dept, U. of N. Carolina, Chapel Hill
Lines: 34
Summary: 

In article <5100014@ccvaxa> aglew@ccvaxa.UUCP writes:

> Now, is this an architectural question:  should or could randomized
> rounding be provided by a floating point unit?  Assuming you can
> cheaply obtain a random number in hardware (amplify transistor
> noise?)  doing randomized rounding in the floating point unit would
> be a lot faster than doing so in software, where you'd have to
> extract and play around with the guard bits.  

Three answers:

1) Certainly; it's a reasonable idea and inexpensive to implement.
(Note that rounding is done for all floating point operations: +, -,
*, /.)

2) As it turns out the error characteristics get even better (or so
I am told) if the rounding is done with probability depending on how
close the exact answer is to the rounded answer.  To illustrate, an
exact answer of 1.00027 (assuming 3 digits produced, i.e., answer
must be either 1.001 or 1.000) would have a probability of .27 of
being rounded UP and a probability of .73 of being rounded DOWN.
This requires about the same amount of hardware as (1).

3) It's all irrelevant because the proposal does not conform to the
IEEE floating point standard.  Good or bad, the IEEE standard will
be observed by designers of "real" products because of pressure from
Marketing.  

A slightly grim view, but take a look around -- I suspect you will
find the point of view in (3) inescapable.

cheers,

Tim