Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!princeton!allegra!alice!ark
From: ark@alice.UUCP
Newsgroups: comp.arch
Subject: Re: Floating point accuracy
Message-ID: <6280@alice.UUCP>
Date: Tue, 11-Nov-86 09:54:40 EST
Article-I.D.: alice.6280
Posted: Tue Nov 11 09:54:40 1986
Date-Received: Tue, 11-Nov-86 20:38:02 EST
References: <340@euroies.UUCP> <1989@videovax.UUCP> <722@mips.UUCP> <267@bath63.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 27

In article <267@bath63.UUCP>, ma_jpb@bath63.UUCP (Bennett) writes:
> I recall that when I was an undergraduate being taught a novel rounding
> scheme for floating point, attributed I believe to David Wheeler of Cambridge
> University.
> 
> The mechanism was to add a random number in the range 0 to 1 in the last digit
> and then truncate. This gives better RMS error than most other rounding
> schemes. It also has the advantage that numerically unstable programs are
> easy to detect (they give wildly differing results on each run).

I suppose the biggest disadvantage of a scheme of this sort is that it
may make some programs very difficult to debug.  Suppose, for example,
that your program blows up, but only sometimes.  That could happen if
a value were randomly rounded very close to a singularity.
How would you debug such a program?

Another serious problem is that many things we take for granted would
no longer be true.  For instance, A+B would no longer always be equal
to B+A.  For that matter, A+B would not be equal to A+B.
There is also the problem of making sure this random rounding is
only applied when the result of the operation is not exact.

Finally, if you're trying to use it to detect unstable algorithms,
I would expect that something like IEEE directed rounding would be
more useful.  Run the program twice -- once rounding up and the other
time rounding down.  I would think that would tell you more about its
numerical stability than running it twice with random rounding.