X3J3/96-171

Date:     November 12, 1996
To:       X3J3
From:     Baker Kearfott
Subject:  Some Reasons why Interval Arithmetic
          Cannot be a Module


This issue has been discussed informally in some depth, in
subgroup and elsewhere. The following are some of the reasons:

1. There are several new defined infix operators in interval computations,
   with a natural precedence among existing operators that cannot be
   specified within a module.

2. I/O must be done with knowledge of the idiosyncracies in
   base conversion.  There is presently no Fortran language facility
   for this.

3. Decimal constants within program statements must be converted with
   knowledge of the idiosyncracies in base conversion, as with I/O.

4. There are various performance and sharpness issues.

Many interval arithmetic modules have indeed been written
in the past, including in Fortran.  However, all such modules suffer
from one or more weaknesses, as above.  In particular, such modules have
executed slowly, do not take full advantage of machine architecture, and
suffer from lack of I/O capabilities.  Removal of these problems would
widen the range of practicality of such computations considerably.


An Elaboration of the Above Four Issues
__ ___________ __ ___ _____ ____ ______

1. There is presently no facility in the language for user-defined
   operator precedence. It has been suggested that interval
   computations should not be unduly demanding on present compiler
   technology in this regard, since the new operators can be put
   into the same class as present operators.  However, it has been
   argued in X3J3 plenary that this is not the case.

2. Interval arithmetic does not make an accuracy demand.  However,
   writing a portable interval module would require the idiosyncracies
   of intrinsic I/O conversion be known for each machine to which
   the module is ported.  This is because the conversion has to
   be such that the result is guaranteed to contain the original
   representation.  There is no present Fortran feature that would
   enable this to be done.

3. The issue here is similar to I/O conversions from the
   point of view of proper outward rounding.  However, there
   is an additional issue:  recognizing interval constants as such
   and properly converting them is impossible to do within the
   present compile time module capabilities.

4. If things were as simple as repeated addition, optimization
   of interval expressions would be fairly straightforward.
   However, general expressions and expressions that involve
   transcendental functions can be optimized by the compiler,
   but not if the operations were implemented within a module.  For
   example, the expression

   SIN(X) + COS(X)

   would be subject to overestimation if evaluated as written,
   since the values of SIN and COS are correlated.  But the
   entire expression can be calculated e.g. as a single SIN function,
   with an altered argument.  This improves both sharpness of the
   result and execution speed.  Similar situations arise with
   EXP, SQRT, etc., where monotonicity properties of the function
   can be utilized.  There are many other situations
   where the compiler could optimize expressions both from the
   point of view of speed and sharpness, but where the optimization
   would not be possible if the operations were implemented
   within a module within the present language.