Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!mcvax!ukc!stc!inset!dave
From: dave@inset.UUCP (Dave Lukes)
Newsgroups: comp.arch
Subject: Re: Floating point accuracy
Message-ID: <1094@inset.UUCP>
Date: Tue, 11-Nov-86 05:46:50 EST
Article-I.D.: inset.1094
Posted: Tue Nov 11 05:46:50 1986
Date-Received: Sat, 15-Nov-86 05:02:07 EST
References: <340@euroies.UUCP> <1989@videovax.UUCP>
Reply-To: dave@inset.UUCP (Dave Lukes)
Organization: The Instruction Set Ltd., London, UK.
Lines: 28

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

Yes, this has been mentioned before on the net.

>Sadly I believe this has never been implemented. Perhaps manufacturers
>couldn't face tracing hardware errors in such a system...

I don't buy that: most hardware these days is IEEE compatible,
with the ability to set the rounding mode:
so you debug your hardware using a deterministic rounding mode,
THEN debug the random stuff.

I think much it's much more likely that manufacturers either haven't heard
of it or don't want to implement it because it complicates things.

-- 

		Dave Lukes. (...!inset!dave)

``Fox hunting: the unspeakable chasing the inedible'' -- Oscar Wilde