Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcnc!unc!rentsch
From: rentsch@unc.cs.unc.edu (Tim Rentsch)
Newsgroups: comp.arch
Subject: Re: IEEE floating point modes
Message-ID: <741@unc.cs.unc.edu>
Date: Sat, 4-Jul-87 00:35:09 EDT
Article-I.D.: unc.741
Posted: Sat Jul  4 00:35:09 1987
Date-Received: Sat, 4-Jul-87 17:20:44 EDT
References: <93900007@hcx1> <22630@sun.uucp>
Reply-To: rentsch@unc.UUCP (Tim Rentsch)
Organization: University of North Carolina, Chapel Hill
Lines: 44

In article <22630@sun.uucp> lyang@sun.UUCP (Larry Yang) writes:
> The rounding to +inf and -inf are especially useful in what is known
> as 'interval arithmetic'.  Since floating point arithmetic has the
> potential of inaccuracies due to rounding, what a programmer may do
> is to perform a computation using 'round to +inf', then repeat the
> computation using 'round to -inf'.  Then they are certain that the
> 'true' result lies somewhere between these two bounds; they know the
> 'interval' in which the solution lies.  

Assuming by "perform a computation" you mean run an entire program
(rather than just one arithmetic operation), this is not right.  It
is perfectly possible (proof left to the reader) for the exact
answer to a calculation be outside the range of 'round to -inf' and
'round to +inf', if the calculation has more than one operation.  

True interval arithmetic requires two operands (lower and upper
bound) to be carried everywhere through the program, generating new
lower and upper bounds for each operation.  For addition, sum the
lower bounds (round to -inf) to get the result lower bound, sum the
upper bounds (round to +inf) to get the result upperbound.  For
subtraction, on the other hand, subtract the lower bound from the
upper bound (round to +inf) to get the result upper bound, subtract
the upper bound from the lower bound (round to -inf) to get the
result lower bound.  And so forth.

The 'round to -inf' and 'round to +inf' could be used to implement
interval arithmetic, as sketched above, but only by carrying twice
as much data, and by doing twice as many operations.

Of course, you could use 'round to -inf' and 'round to +inf' as
confidence checks.  If the program run the two ways produces
significantly different results (or even if the two similar results
are significantly different from 'round to nearest'), then it is
certain that there is lost significance, and so you had better do
some numerical analysis (or use double precision) before trusting
the answers.  By a standard (perhaps suspect) reasoning process, if
the two -- or three -- answers substantially agree, our confidence
in the results is increased.  This increased confidence (or clear
indication of erroneous answer) comes with only a 2-3 fold increase
in CPU time, and with no change in program.

cheers,

Tim