Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: comp.arch Subject: Re: IEEE floating point modes (interval arithmetic and division) Message-ID: <8254@utzoo.UUCP> Date: Mon, 6-Jul-87 14:30:22 EDT Article-I.D.: utzoo.8254 Posted: Mon Jul 6 14:30:22 1987 Date-Received: Mon, 6-Jul-87 14:30:22 EDT References: <93900007@hcx1> <22630@sun.uucp>, <2774@phri.UUCP> Organization: U of Toronto Zoology Lines: 18 > ... for division, i.e. if you do (a+b)/(c+d), this logic doesn't > hold. If a+b = 1.1 and c+d = 1.9, for example, rounding both intermediate > results towards -inf gives 1.0/1.0 = 1.0; similarly, rounding both towards > +inf gives 2.0/2.0 = 1.0. The "real" answer is 0.578..., which is *not* > within the interval (1.0,1.0). Doing interval arithmetic correctly is rather more complicated than just running the calculation twice with different rounding modes. You have to consider the worst cases for each operation. For example, the worst cases for division round numerator and denominator in different ways. It gets worse than that when the function isn't monotonic. Taking a gross case, sin(0) = sin(pi) = 0, but sin(0...pi) is 0...1 because sin(pi/2) is 1. Getting all this right, especially when roundoff error in "hidden" intermediate results is involved, really requires a professional. The extra rounding modes are tools, not ready-made solutions. -- Mars must wait -- we have un- Henry Spencer @ U of Toronto Zoology finished business on the Moon. {allegra,ihnp4,decvax,pyramid}!utzoo!henry