First of all, you need to select your base type. In order to obtain an useful interval type, the numbers should respect some requirements. Please refer to this page in order to see them. When your base type is robust enough, you can go to the next step: the choice of the policies.
As you should already know if you did not come to this page by accident,
the interval class expect a policies argument describing the
rounding and checking
policies. The first thing to do is to verify if the default policies are or
are not adapted to your case. If your base type is not float,
double, or long double, the default rounding
policy is probably not adapted. However, by specializing
interval_lib::rounded_math to your base type, the default
rounding policy will be suitable.
The default policies define an interval type that performs precise
computations (for float, double, long
double), detects invalid numbers and throws exception each times an
empty interval is created. This is a brief description and you should refer
to the corresponding sections for a more precise description of the default
policies. Unless you need some special behavior, this default type is
usable in a lot of situations.
After having completely defined the interval type (and its policies),
the only thing left to do is to verify that the constants are defined and
std::numeric_limits is correct (if needed). Now you can use
your brand new interval type.
If you use the interval library in order to solve equation and
inequation systems by bisection, something like
boost::interval<double> is probably what you need. The
computations are precise, and they may be fast if enclosed in a protected
rounding mode block (see the performance
section). The comparison are "certain"; it is probably the most used type
of comparison, and the other comparisons are still accessible by the
explicit comparison functions. The checking forbid empty interval; they are
not needed since there would be an empty interval at end of the computation
if an empty interval is created during the computation, and no root would
be inside. The checking also forbid invalid numbers (NaN for floating-point
numbers). It can be a minor performance hit if you only use exact
floating-point constants (which are clearly not NaNs); however, if
performance really does matter, you will probably use a good compiler which
knows how to inline functions and all these annoying little tests will
magically disappear (if not, it is time to upgrade your compiler).
You may want to use the library on intervals with imprecise bounds or on inexact numbers. In particular, it may be an existing algorithm that you want to rewrite and simplify by using the library. In that case, you are not really interested by the inclusion property; you are only interested by the computation algorithms the library provides. So you do not need to use any rounding; the checking also may not be useful. Use an "exact computation" rounding (you are allowed to think the name strangely applies to the situation) and a checking that never tests for any invalid numbers or empty intervals. By doing that, you will obtain library functions reduced to their minimum (an addition of two intervals will only be two additions of numbers).
The inputs of your program may be empty intervals or invalid values (for
example, a database can allow undefined values in some field) and the core
of your program could also do some non-arithmetic computations that do not
always propagate empty intervals. For example, in the library, the
hull function can happily receive an empty interval but not
generate an empty interval if the other input is valid. The
intersect function is also able to produce empty intervals if
the intervals do not overlap. In that case, it is not really interesting if
an exception is thrown each time an empty interval is produced or an
invalid value is used; it would be better to generate and propagate empty
intervals. So you need to change the checking policy to something like
interval_lib::checking_base<T>.
This example does not deal with a full case, but with a situation that can occur often. Sometimes, it can be useful to change the policies of an interval by converting it to another type. For example, this happens when you use an unprotected version of the interval type in order to speed up the computations; it is a change of the rounding policy. It also happens when you want to temporarily allow empty intervals to be created; it is a change of the checking policy. These changes should not be prohibited: they can greatly enhance a program (lisibility, interest, performance).
Revised 2006-12-24
Copyright © 2002 Guillaume Melquiond, Sylvain Pion, Hervé Brönnimann, Polytechnic University
Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)