levy@ttrdc.UUCP (Daniel R. Levy) (03/03/86)
<Oh oh here it comes. Watch out boy, it'll chew you up! \ Oh oh here it comes. The LINE EATER! [Line eater]> In article <5059@alice.uUCp>, ark@alice.UucP (Andrew Koenig) 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. >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? Random floating point thoughts... :-) I can just see it, a new mauctl() system call (for the 3B2/5/15'ers :-). What about OTHER processes which were also using the floating point unit? They'd get screwed, wouldn't they, unless the floating point behavior was modifiable on a per-process basis? 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 might all be calling for it) and that it would always start the same way? If so might this alleviate some of the debugging difficulties? (Only trouble is then that debugging statements had better use the unit an even number of times or you're right back where you started...) Maybe the default random-rounding state should be OFF for the floating point unit. [Gentle flame on...] I think that more important than the random rounding issue would be to CLEAN UP THE ACT of the various math libraries in common use! (Is there an ANSI standard either existing or in the works for math libraries?) In a recent news article by (I think) Gene Spafford, it is pointed out that the situation is horrible for many math libraries. I have found that on the same computer (a VAX 8600) the results of a trivial SPICE simulation run were quite different when the VMS math libraries were used versus Unix (Eunice-- a 4.1 BSD emulation under VMS) math libraries. (On a SysV 3B20, the results matched the VMS ones fairly closely, which seems to point blame away from the [Fortrash] compiler and the floating point implementation and toward the lib- raries.) It is my belief that results would diverge a lot less between different machines if the math libraries were simply cleaned up and standard- ized. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy
dick@ucsfcca.UUCP (Dick Karpinski) (03/12/86)
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