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