Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!sun!dgh
From: dgh@sun.uucp (David Hough)
Newsgroups: net.arch
Subject: Re: Random Rounding in Floating Point
Message-ID: <3316@sun.uucp>
Date: Mon, 3-Mar-86 21:01:58 EST
Article-I.D.: sun.3316
Posted: Mon Mar  3 21:01:58 1986
Date-Received: Wed, 5-Mar-86 05:44:21 EST
References: <11896@ucbvax.BERKELEY.EDU> <5100014@ccvaxa> <1068@unc.unc.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 25

> 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.

I hadn't noticed that marketing pressure has caused Cray, DEC or IBM 
to retrofit their mainframes or minis to meet the IEEE standard!

Random rounding was not considered formally by the IEEE floating point working
group because no one suggested it.  I can't speak for others,
but error analysts who produce error bounds for a living are usually
concerned with worst-case errors which random rounding exacerbates.

Even people who are not error analysts might not enjoy debugging programs
whose results vary from run to run.  So the idea was not suggested and
would have received short shrift if it had been, since the working group
was trying to come up with the best standard for general-purpose
computation.  That prevents nobody from implementing
random rounding and demonstrating the alleged advantages, which may be
quite real for specific applications.  In particular there's nothing to
prevent one from offering random rounding along with the four required
deterministic rounding modes.