Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 alpha 4/3/85; site ukma.UUCP Path: utzoo!watmath!clyde!cbosgd!ukma!sambo From: sambo@ukma.UUCP (Father of micro-S) Newsgroups: net.arch Subject: Re: Floating Point Rounding Message-ID: <2028@ukma.UUCP> Date: Tue, 6-Aug-85 01:01:59 EDT Article-I.D.: ukma.2028 Posted: Tue Aug 6 01:01:59 1985 Date-Received: Tue, 6-Aug-85 12:27:02 EDT References: <36900010@ima.UUCP> <1357@peora.UUCP> <1117@ihuxb.UUCP> Reply-To: sambo@ukma.UUCP (Father of micro-S) Organization: Univ. of KY Mathematical Sciences Lines: 74 Summary: Knuth has some good discussion on rounding In article <1117@ihuxb.UUCP> wfmans@ihuxb.UUCP (w. mansfield) writes: >> ... (discussion of plain ordinary rounding) >> So far, this is plain, ordinary rounding. But now comes the problem. If >> the most-significant guard digit is 8, and all other guard digits are zero, >> you have a dilemma. If you always round down, the result will come out >> "too small" (we're speaking here in terms of absolute values); if you >> always round up, it will come out "too large". So... if all other guard >> digits are 0, the least significant bit of the low-order digit of the >> mantissa is FORCED to 1. Volume 2 of Knuth's The Art of Computer Programming (1981) has a good dis- cussion of rounding on pp. 221-23. Let me quote a bit from it: "No rounding rule can be best for every application.... But for most numerical calculations the best policy appears to be the rounding scheme ... which insists that the least significant digit should al- ways be made even (or always odd) when an ambiguous value is rounded. This is not a trivial technicality, of interest only to nit-pickers; it is an important practical consideration, since the ambiguous case arises surprisingly often and a biased rounding rule produces signi- ficantly poor results.... For even radices, there is reason to prefer the following rule: `Round to even when b/2 is odd, round to odd when b/2 is even.' [B is the radix.] ... On the other hand, some people prefer rounding to even in all cases, so that the remainder will tend to be 0 more often. Neither alternative conclusively dominates the other; fortunately the base is usually b = 2 or b = 10, when everyone agrees that round to even is best." Well, almost everyone. Above is a counterexample, or was the radix 16? I don't remember. Anyway, IEEE does it right. See below. >I'd like to point you folks toward the IEEE 754 floating point standard and >Round to nearest is the mode discussed above. >In the case referred to above (in IEEE language, where the two nearest >representable values are equally near the infinitely precise value), the one >with the least significant bit zero will be returned. >> However, very sadly, in the real world, "better" is not always good enough. >> As a result, R* rounding is not that popular, >> eventhough there is a large body of theory behind it showing that it is >> a "better" rounding scheme than the IBM approach. Knuth seems to really attack the IBM approach: "Many people feel that, since floating point arithmetic is inexact by nature, there is no harm in making it just a little bit less exact in certain rare cases, if it is convenient to do so. This policy saves a few cents in the design of computer hardware, or a small percentage of the average running time of a subroutine. But the above discussion shows that such a policy is mistaken.... The reason is not to glorify `bit chasing'; a more fundamental issue is at stake here: `Numerical subroutines should deliver results that satisfy simple, useful mathema- tical laws whenever possible.' [The single quotes are mine; the origi- nal is italicized.] The crucial formula u `+' v = round(u + v) is a `regularity' property that makes a great deal of difference between whether mathematical analysis of computational algorithms is worth doing or worth avoiding. Without any underlying symmetry properties, the job of proving interesting results becomes extremely unpleasant. `The enjoyment of one's tools is an essential ingredient of successful work.'" [The single quotes are mine; the original is italicized.] >Another part of the problem is that the folks who write specifications for >computer languages (Ada excluded) don't specify the type of arithmetic >to be performed. Basically they wimp out and say "the answer you get >depends on the hardware". This is especially true where floating point >is concerned. Another example of a language that avoids this problem is micro-S. (If you don't know what micro-S is, you can ask me.) ----------------------------------------- Samuel A. Figueroa, Dept. of CS, Univ. of KY, Lexington, KY 40506-0027 ARPA: ukma!sambo<@ANL-MCS>, or sambo%ukma.uucp@anl-mcs.arpa, or even anlams!ukma!sambo@ucbvax.arpa UUCP: {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!sambo, or cbosgd!ukma!sambo "Micro-S is great, if only people would start using it."