You may want to adapt the Makefile to suit your C++ compiler and its
options. I've tested the package on gcc 2.95.2, and I hope I've
removed all things which prevented Microsoft Visual C++ 6.0 SP3
from compiling it as well.

If you have any suggestions for improvement, please send them in.
In particular, I feel that the name of the current "dist" function
is unintuitive.

Originally, I only intended the package to assess rounding errors
in lengthy computations. Since then, I've learned that there
are other application domains where interval arithmetic is useful,
so I've provided some utility functions for set-like operations,
affine transforms etc. as well.

What is the current preference among the numeric computing community
regarding behavior on out-of-range argument values? I've read
W. Kahan's "Lecture Notes on the Status of IEEE Standard 754 for
Binary Floating Point Arithmetic" which seems to imply that
raising exceptions has growing support. C++ provides language-based
exceptions, but they are not required to be raised for illegal
floating-point operations.

The over-arching advantage of this new interval class is that it would
be suitable for acceptance into the C++ standard. The core interface
follows the design principles used for the C++ std::complex class.
This uniform standard interface is particularly important for modern
C++ libraries that use generic programming, and allows intervals to be
used seemlessly in place of other numeric types. In terms of the
functionality and implementation, the class is quite similar to the
existing interval arithematic software that I have seen. The design
goal of this interval class was to take the best features of the
existing software, and package it in an interface that follows C++
stardard guidelines.

The group of C++ experts at
www.boost.org
(many of whom are on the C++
stardard committee) has reviewed this interval class to ensure that
the interface would be appropriate for standardization. It would be
excellent if the reliable computing community also reviewed this
class, to ensure that the functionality meets your needs, and
that the implementation provides that functionality in a
high-quality manner.

Abstract: Three extended real interval systems are defined and
distinguished by their implementation complexity and result sharpness.
The three systems are closed with respect to interval arithmetic and the
enclosure of functions and relations, notwithstanding domain restrictions
or the presence of singularities.

Thank you very much for the helpful comments and documentation
pointers.

Thanks to your comments and after reading some of the papers, I
know that my implementation is lacking. However, I feel that the
important issue is the interface; after the interface is agreed
upon, the implementation can be repaired easily.

With a common interface where all C++ interval packages agree,
the implementation becomes interchangeable. This allows for

common and peer-reviewed quality tests

common and peer-reviewed performance tests

common application software

formal standardization

vendor-provided optimized implementations

I understand that Dmitri Chiriaev and William Walster did exactly
that for a FORTRAN extension.

There are several interval packages in existence, which all have
different interfaces. This not only concerns function names,
but also semantics. Let me highlight a few differences which
hamper re-use of application software with different interval
packages:

Allowing for different base types (float, double, even a non-builtin
rational type) may sound far-fetched for most interval arithmetic
application domains. However, there is no mathematical reason to forbid
them, and they can be useful. For example, if the usual 64 bits of a
"double" (53 bits mantissa) are not enough for some computations, there
may arise the necessity to employ an extended-precision real class from
some other source. It would be a pity if one had to re-implement
interval arithmetics just to use that "better" real class.

We could specify that the FPU rounding mode is undefined after
some interval arithmetic operation, or that it will not be altered,
i.e. rounding mode changes are always local to an operation. The
latter specification is useful if you mix interval and point
arithmetic, for example. From a software design perspective, I think
it is inacceptable to have an indeterminate rounding mode after
some interval arithmetic operation, rendering all future built-in
point operations invalid.

Behaviour on illegal operations such as sqrt(-1): Throw an exception,
or do your best and continue (see the specification by Dmitri Chiriaev
and William Walster). From a C++ software design perspective, I think
it is inacceptable to just terminate the program, but on the other
hand, continuing might be inappropriate as well. That's where C++
exceptions come in handy.

Behaviour of overloaded operator < : There is the choice of
certainly-less-than, possibly-less-than and subset-of.

From a software design perspective, the use of macros (instead of
template parameters) is not desirable. I shall check out the
performance disadvantage for templates claimed by Juergen Wolff
von Gudenberg in the paper advertised in his mail. Frankly, I have
a hard time believing it.

I understand that the decision in some of these items depends on
the application domain, and thus the item should be a configuration
option for the interval class. It seems important to me to identify
the resulting space of configuration options.

>I understand that Dmitri Chiriaev and William Walster did exactly
>that for a FORTRAN extension.

We almost convinced the Fortran committee of requiring an
intrinsic interval type in the standard. As a member of those
committees (US X3J3 and international WG5), I organized input
to the committee for two years. For about half of this time,
an interval data type was a stated requirement for Fortran 2000.
In the end, some disagreements within the interval community
coupled with resistance on the part of some vendors to a
technology they perceived as different, untested and with uncertain
demand, killed the requirement. I have archives from a mailing
list for discussion of the proposed standard. There are also
other documents associated with the standardization effort.

The Chiriaev / Walster (and others) implementation within Sun's
Fortran compiler benefits from the standardization effort, but
goes beyond it in several ways. Most importantly, Walster et al
have put effort into considering intervals resulting from
operations such as [1,2] / [-1,1] or SQRT([-1,1]) to develop
an exception-free system (using infinities for end points).

Precursors to the standardization effort are Walster's early
library INTLIB, a library for an intrinsic Fortran data type
for the Minnesota M77 compiler for CYBER 175 machines, and
my Fortran 90 module INTERVAL_ARITHMETIC (ACM TOMS Algorithm 763).
(My module uses the FORTRAN 77 module INTLIB, although it is
unrelated to Walster's work; I was unaware that Bill had named
his library INTLIB when I developed my INTLIB.)

Wolfgang Walter II has also been a player in the standardization
process for intervals, especially as head of the German delegation
to the international committee. He also developed a module that
partially implements the proposed standard of the time.

I am hoping that we will all examine Sun's Fortran compiler. We
may or may not agree with precise details, but, in any case, it
represents a milestone from which we can start, if we perceive
we need to go further. We should send our comments, suggestions,
and criticism either here or to a support mailing list at

Bill Walster
(Bill.Walster@eng.sun.com),
Sun Microsystems, adds:
For sure, our soon to be released compiler has benefitted from the
helpful work, comments and suggestions of many people, including
Baker and those he listed, above. We hope the above mailing list
will be actively used as a forum for getting questions answered and
to express positive and negative comments.

Jens Maurer:

> - We could specify that the FPU rounding mode is undefined after
>some interval arithmetic operation, or that it will not be altered,
>i.e. rounding mode changes are always local to an operation. The
>latter specification is useful if you mix interval and point
>arithmetic, for example. From a software design perspective, I think
>it is inacceptable to have an indeterminate rounding mode after
>some interval arithmetic operation, rendering all future built-in
>point operations invalid.

Yes, specifying "undefined" allows some wiggle-room. In particular,
different computer architectures switch rounding modes in different
ways. Interval arithmetic can be efficiently implemented with
just a single rounding mode (either "round-down" or "round-up");
that, I think, is an efficient option for most architectures. Otherwise,
the best architecture for doing a sequence of unrelated computations
interspersed with floating-point computations appears to be
associating the rounding mode with the operation itself, rather
than with a flag that is switched in the FPU.

If the architecture
is unknown, specifying that the rounding mode is "undefined" after
an operation lets the interval operations be efficient, but may
cause inefficiencies later due to having to change the rounding
mode back to a desired value.

Bill Walster
(Bill.Walster@eng.sun.com),
Sun Microsystems, adds:
In our f95 implementation, we guarantee that intervals do not produce any
side effects on non-interval code. In particular, we "logically" restore the
rounding mode after every interval operation.

Jens Maurer:

> - Behaviour on illegal operations such as sqrt(-1): Throw an exception,
>or do your best and continue (see the specification by Dmitri Chiriaev
>and William Walster). From a C++ software design perspective, I think
>it is inacceptable to just terminate the program, but on the other
>hand, continuing might be inappropriate as well. That's where C++
>exceptions come in handy.

The above has been the subject of some controversy. My perception
is that, in some contexts, you will want to throw an exception,
and, in others, you will want to continue.

Fortran does not have
user-defined exceptions. The reasons, as I understand them,
include efficiency. Fortran is a very good array-processing language,
and there are major questions about what to do if an exception
occurs in a component while an array operation is executing on
an advanced-architecture machine.

Bill Walster
(Bill.Walster@eng.sun.com),
Sun Microsystems, adds:
The system we have implemented in f95 is set-based. The result of an operation
or function evaluated at a point that is outside the closure of its domain is
the empty set, or empty interval. Depending on the context, an empty result of
an arithmetic operation or function evaluation may or may not indicate that
an error has been made.

An exception-like feature is needed to provide a test for expression
continuity, which is an assumption for the interval Newton algorithm and the
Brouwer fixed-point theorem. This will only be needed in special circumstances
and therefore needs to be invokable only when required.

Jens Maurer:

> - Behaviour of overloaded operator< : There is the choice of
>certainly-less-than, possibly-less-than and subset-of.

My reading is that the most commonly used meaning is
"certainly less than", although others may disagree :-) In my
view, the important thing is that non-interval-experts using
interval arithmetic understand the distinction.

Bill Walster
(Bill.Walster@eng.sun.com),
Sun Microsystems, adds:
The most important practical application for this syntactic sugar I have
uncovered is to make it easy to construct "complete" sets of relational
statements. This is important to avoid hiding an empty result that
could be the indication of an error condition.
Otherwise, depending on the application, one or the other sense of
relational operator may be what makes the most sense in the particular
context.

Jens Maurer:

> - From a software design perspective, the use of macros (instead of
>template parameters) is not desirable. I shall check out the
>performance disadvantage for templates claimed by Juergen Wolff
>von Gudenberg in the paper advertised in his mail. Frankly, I have
>a hard time believing it.

Can we race J{\"u}rgen's package and yours under similar conditions?

By the way, in developing template-like features in Fortran 200x,
a consideration of the standardization committee was "avoiding
performance hits as you see in C++".