Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucsfcca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!ucsfcgl!ucsfcca!dick
From: dick@ucsfcca.UUCP (Dick Karpinski)
Newsgroups: net.arch
Subject: Re: Floating point
Message-ID: <451@ucsfcca.UUCP>
Date: Tue, 11-Mar-86 20:44:45 EST
Article-I.D.: ucsfcca.451
Posted: Tue Mar 11 20:44:45 1986
Date-Received: Fri, 14-Mar-86 05:37:33 EST
References: <5100014@ccvaxa> <5059@alice.uUCp> <767@ttrdc.UUCP>
Reply-To: dick@ucsfcca.UUCP (Dick Karpinski)
Organization: UCSF Computer Center
Lines: 22

In article <767@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>
>Would it work as well to set up the floating point unit so that the way it
>rounds would alternate from one way to the other each time that a given
>PROCESS used it (not just every time it was used, since several processes

What seems to work just about as well as random or alternating bias in
rounding is what the IEEE 754 standard requires in round-to-nearest:
choose the direction (when both are equally sensible) that makes the
result even.  This depends on the lack of bias in the next bit up to
achieve unbiased results.  And IF the next operation is to divide by
two (a common case), no additional error is introduced there.  This
should not introduce non-determinism gratuitously.  Maxim: roundoff
errors dominate other computational numerical errors.

Dick
-- 

Dick Karpinski    Manager of Unix Services, UCSF Computer Center
UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick   (415) 476-4529 (12-7)
BITNET: dick@ucsfcca   Compuserve: 70215,1277  Telemail: RKarpinski
USPS: U-76 UCSF, San Francisco, CA 94143