1 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" |
---|
2 | "http://www.w3.org/TR/html4/loose.dtd"> |
---|
3 | <html> |
---|
4 | <head> |
---|
5 | <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
---|
6 | <link rel="stylesheet" type="text/css" href="../../../../boost.css"> |
---|
7 | <title>Choosing Your Own Interval Type</title> |
---|
8 | </head> |
---|
9 | |
---|
10 | <body lang="en"> |
---|
11 | <h1>Choosing Your Own Interval Type</h1> |
---|
12 | |
---|
13 | <p>First of all, you need to select your base type. In order to obtain an |
---|
14 | useful interval type, the numbers should respect some requirements. Please |
---|
15 | refer to <a href="numbers.htm">this page</a> in order to see them. When your |
---|
16 | base type is robust enough, you can go to the next step: the choice of the |
---|
17 | policies.</p> |
---|
18 | |
---|
19 | <p>As you should already know if you did not come to this page by accident, |
---|
20 | the <code>interval</code> class expect a policies argument describing the <a |
---|
21 | href="rounding.htm">rounding</a> and <a href="checking.htm">checking</a> |
---|
22 | policies. The first thing to do is to verify if the default policies are or |
---|
23 | are not adapted to your case. If your base type is not <code>float</code>, |
---|
24 | <code>double</code>, or <code>long double</code>, the default rounding policy |
---|
25 | is probably not adapted. However, by specializing |
---|
26 | <code>interval_lib::rounded_math</code> to your base type, the default |
---|
27 | rounding policy will be suitable.</p> |
---|
28 | |
---|
29 | <p>The default policies define an interval type that performs precise |
---|
30 | computations (for <code>float</code>, <code>double</code>, <code>long |
---|
31 | double</code>), detects invalid numbers and throws exception each times an |
---|
32 | empty interval is created. This is a brief description and you should refer |
---|
33 | to the corresponding sections for a more precise description of the default |
---|
34 | policies. Unless you need some special behavior, this default type is usable |
---|
35 | in a lot of situations.</p> |
---|
36 | |
---|
37 | <p>After having completely defined the interval type (and its policies), the |
---|
38 | only thing left to do is to verify that the constants are defined and |
---|
39 | <code>std::numeric_limits</code> is correct (if needed). Now you can use your |
---|
40 | brand new interval type.</p> |
---|
41 | |
---|
42 | <h2>Some Examples</h2> |
---|
43 | |
---|
44 | <h3>Solving systems</h3> |
---|
45 | |
---|
46 | <p>If you use the interval library in order to solve equation and inequation |
---|
47 | systems by bisection, something like |
---|
48 | <code>boost::interval<double></code> is probably what you need. The |
---|
49 | computations are precise, and they may be fast if enclosed in a protected |
---|
50 | rounding mode block (see the <a href="rounding.htm#perf">performance</a> |
---|
51 | section). The comparison are "certain"; it is probably the most used type of |
---|
52 | comparison, and the other comparisons are still accessible by the explicit |
---|
53 | comparison functions. The checking forbid empty interval; they are not needed |
---|
54 | since there would be an empty interval at end of the computation if an empty |
---|
55 | interval is created during the computation, and no root would be inside. The |
---|
56 | checking also forbid invalid numbers (NaN for floating-point numbers). It can |
---|
57 | be a minor performance hit if you only use exact floating-point constants |
---|
58 | (which are clearly not NaNs); however, if performance really does matter, you |
---|
59 | will probably use a good compiler which knows how to inline functions and all |
---|
60 | these annoying little tests will magically disappear (if not, it is time to |
---|
61 | upgrade your compiler).</p> |
---|
62 | |
---|
63 | <h3>Manipulating wide intervals</h3> |
---|
64 | |
---|
65 | <p>You may want to use the library on intervals with imprecise bounds or on |
---|
66 | inexact numbers. In particular, it may be an existing algorithm that you want |
---|
67 | to rewrite and simplify by using the library. In that case, you are not |
---|
68 | really interested by the inclusion property; you are only interested by the |
---|
69 | computation algorithms the library provides. So you do not need to use any |
---|
70 | rounding; the checking also may not be useful. Use an "exact computation" |
---|
71 | rounding (you are allowed to think the name stangely applies to the |
---|
72 | situation) and a checking that never tests for any invalid numbers or empty |
---|
73 | intervals. By doing that, you will obtain library functions reduced to their |
---|
74 | minimum (an addition of two intervals will only be two additions of |
---|
75 | numbers).</p> |
---|
76 | |
---|
77 | <h3>Computing ranges</h3> |
---|
78 | |
---|
79 | <p>The inputs of your program may be empty intervals or invalid values (for |
---|
80 | example, a database can allow undefined values in some field) and the core of |
---|
81 | your program could also do some non-arithmetic computations that do not |
---|
82 | always propagate empty intervals. For example, in the library, the |
---|
83 | <code>hull</code> function can happily receive an empty interval but not |
---|
84 | generate an empty interval if the other input is valid. The |
---|
85 | <code>intersect</code> function is also able to produce empty intervals if |
---|
86 | the intervals do not overlap. In that case, it is not really interesting if |
---|
87 | an exception is thrown each time an empty interval is produced or an invalid |
---|
88 | value is used; it would be better to generate and propagate empty intervals. |
---|
89 | So you need to change the checking policy to something like |
---|
90 | <code>interval_lib::checking_base<T></code>.</p> |
---|
91 | |
---|
92 | <h3>Switching interval types</h3> |
---|
93 | |
---|
94 | <p>This example does not deal with a full case, but with a situation that can |
---|
95 | occur often. Sometimes, it can be useful to change the policies of an |
---|
96 | interval by converting it to another type. For example, this happens when you |
---|
97 | use an unprotected version of the interval type in order to speed up the |
---|
98 | computations; it is a change of the rounding policy. It also happens when you |
---|
99 | want to temporarily allow empty intervals to be created; it is a change of |
---|
100 | the checking policy. These changes should not be prohibited: they can greatly |
---|
101 | enhance a program (lisibility, interest, performance).</p> |
---|
102 | <hr> |
---|
103 | |
---|
104 | <p>Revised: 2003-01-15<br> |
---|
105 | Copyright (c) Guillaume Melquiond, Sylvain Pion, Hervé Brönnimann, 2002.<br> |
---|
106 | Polytechnic University.</p> |
---|
107 | </body> |
---|
108 | </html> |
---|