rentsch@unc.UUCP (Tim Rentsch) (03/02/86)
In article <5100014@ccvaxa> aglew@ccvaxa.UUCP writes: > Now, is this an architectural question: should or could randomized > rounding be provided by a floating point unit? Assuming you can > cheaply obtain a random number in hardware (amplify transistor > noise?) doing randomized rounding in the floating point unit would > be a lot faster than doing so in software, where you'd have to > extract and play around with the guard bits. Three answers: 1) Certainly; it's a reasonable idea and inexpensive to implement. (Note that rounding is done for all floating point operations: +, -, *, /.) 2) As it turns out the error characteristics get even better (or so I am told) if the rounding is done with probability depending on how close the exact answer is to the rounded answer. To illustrate, an exact answer of 1.00027 (assuming 3 digits produced, i.e., answer must be either 1.001 or 1.000) would have a probability of .27 of being rounded UP and a probability of .73 of being rounded DOWN. This requires about the same amount of hardware as (1). 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. cheers, Tim
dgh@sun.uucp (David Hough) (03/04/86)
> 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.