Roundoff is the bane of numerical computing. Floating point operations can produce arbitrarily inaccurate values. When these values are then used to perform even more calculations, the round-off error will be magnified, creating misleading and unreliable results. Imagine a physicist performing a series of operations on the data she collected. At the end of the day, she will not know how accurate her results are. In the worst case, they may even be entirely meaningless. The problem is reaches beyond having an error in the result. The real issue here, is that the physicist doesn’t have a _bound_ on the error, and thus cannot determine how trust-worthy the results are. Here, Interval Arithmetic comes to the rescue. It works like this: for every calculation, in stead of working with a single floating point number, we work on an interval of numbers. For example, the interval [a, b] represents be the set of numbers greater than a, but less than b. For every operation on this interval, we find an upper bound and a lower bound on the interval.

For example, take the operation [3,4] + [2,5]. The minimum value achievable for the addition in these two intervals is 5, and the maximum possible value is 9. And thus, [3,4] + [2,5] = [5,9]

As another example, divide 10 by 3. Notice that this division cannot be represented exactly, and thus, we need to perform rounding. Our interval calculator gives tells us this: [10, 10] / [3, 3] = [3.3333333, 3.33333334]. Notice that the we rounded down for the lower bound, and rounded up for the upper bound.

How do we handle number comparisons with interval arithmetic? There is a difference between the comparisons [3,5] < [4,6] and [3,4] < [5,6]. In the first case, the comparison might evaluate to true, in the second case, it certainly will. Thus, we introduce several new operators:

CEQ - Certainly equals
CNE - Certainly not equals
CLT - Certainly less than
CLE - Certainly less-than-or-equal-to
CGT - Certainly greater than
CGE - Certainly greater-than-or-equal-to
PEQ - Possibly equals
PNE - Possibly not equals
PLT - Possibly less than
PLE - Possibly less-than-or-equal-to
PGT - Possibly greater than
PGE - Possibly greater-than-or-equal-to

As an example, the comparison [3,5] CLT [4,6] evaluates to false, whereas [3,5] PLT [4,6] evaluates to true.

A notable language, that was designed with the idea of numerical intervals in mind is Frink, [1] which gives a nice introduction on interval arithmetic. However, some languages actually make it impossible to perform interval arithmetic, such as Java, which does not support IEEE754’s directional rounding.

So this sounds extremely useful. Why is interval arithmetic not used more frequently? Well, besides the fact that many programming languages do not support its use, there are a few issues. First of all, there are many functions who’se upper and lower bounds are non-trivial, or at least very slow to compute. In Frink’s implementation, for example, the functions sin() and cos() will be much slower when performed on an interval, than on floating point numbers. The second issue is termed the “dependence problem.” Here is an example that demonstrates the problem: We would expect the calculations x^2 and x*x to return the same result. Let’s see what this looks like using interval arithmetic.

Let x = [-2,2]. Then,
x^2 = [-2,2]^2 = [0,4]
x*x = [-2,2] * [-2,2] = [-4,4]

That is, for x*x, our interval is twice as large as expected! Our interval has become larger than expected. Moore first prooved that if every calculation, our interval appears only once, then our result interval will be tight, that is, no larger than necessary. However, if a variable occurs multiple times in an equation, our interval may become unnecessarily large, as with the x*x case.

In conclusion, even though interval arithmetic is not without problems, it can be very useful in numerical applications.