Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site ccvaxa
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: net.arch
Subject: Re: Oh no! More integer division
Message-ID: <5100020@ccvaxa>
Date: Mon, 3-Mar-86 01:29:00 EST
Article-I.D.: ccvaxa.5100020
Posted: Mon Mar  3 01:29:00 1986
Date-Received: Tue, 4-Mar-86 05:06:51 EST
References: <11896@ucbvax.BERKELEY.EDU>
Lines: 16
Nf-ID: #R:ucbvax.BERKELEY.EDU:11896:ccvaxa:5100020:000:810
Nf-From: ccvaxa.UUCP!aglew    Mar  3 00:29:00 1986


> /* Written  4:17 pm  Feb 28, 1986 by ark@alice.UucP in ccvaxa:net.arch */
> > Now, is this an architectural question: should or could randomized 
> > rounding be provided by a floating point unit? ...
> 
> If randomized rounding is provided by a floating-point unit,
> it had better be easy to turn off because using it is likely
> to make debugging impossible.  Consider: if you run the same
> program twice and get slightly different results, how will you
> ever know if it is a bug in the program?

True enough, and you can't reproduce transistor noise. But little pseudo-
random pattern generators could be placed in the floating point unit,
reseeded when you want reproducibility. The advantage would be, that the
work necessary to make the pseudo-random decision could be done in parallel,
in hardware.