| 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>Numbers Requirements</title> |
|---|
| 8 | </head> |
|---|
| 9 | |
|---|
| 10 | <body lang="en"> |
|---|
| 11 | <h1>Numbers Requirements</h1> |
|---|
| 12 | |
|---|
| 13 | <p>What we call "number" is the base type of the <code>interval</code> class. |
|---|
| 14 | The interval library expect a lot of properties from this base type in order |
|---|
| 15 | to respect the inclusion property. All these properties are already detailed |
|---|
| 16 | in the other sections of this documentation; but we will try to summarize |
|---|
| 17 | them here.</p> |
|---|
| 18 | |
|---|
| 19 | <h3>Ordering</h3> |
|---|
| 20 | |
|---|
| 21 | <p>The numbers need to be supplied with an ordering. This ordering expresses |
|---|
| 22 | itself by the operators <code>< <= => > == !=</code>. It must be |
|---|
| 23 | a total order (reflexivity, antisymmetry, transitivity, and each pair of |
|---|
| 24 | numbers is ordered). So <code>complex<T></code> will not be a good |
|---|
| 25 | candidate for the base type; if you need the inclusion property of interval |
|---|
| 26 | property, you should use <code>complex< interval<T> ></code> in |
|---|
| 27 | place of <code>interval< complex<T> ></code> (but unfortunately, |
|---|
| 28 | <code>complex</code> only provides specialization).</p> |
|---|
| 29 | |
|---|
| 30 | <p>Please note that invalid numbers are not concerned by the order; it can |
|---|
| 31 | even be conceptually better if a comparison with these invalid numbers is |
|---|
| 32 | always <code>false</code> (except for <code>!=</code>). If your checking |
|---|
| 33 | policy uses <code>interval_lib::checking_base</code> and your base type |
|---|
| 34 | contains invalid numbers, then this property is needed: <code>nan!=nan</code> |
|---|
| 35 | (here <code>nan</code> is an invalid number). If this property is not |
|---|
| 36 | present, then you should not use <code>checking_base</code> directly.</p> |
|---|
| 37 | |
|---|
| 38 | <p>Interval arithmetic involves a lot of comparison to zero. By default, they |
|---|
| 39 | are done by comparing the numbers to <code>static_cast<T>(0)</code>. |
|---|
| 40 | However, if the format of the numbers allows some faster comparisons when |
|---|
| 41 | dealing with zero, the template functions in the |
|---|
| 42 | <code>interval_lib::user</code> namespace can be specialized:</p> |
|---|
| 43 | <pre>namespace user { |
|---|
| 44 | template<class T> inline bool is_zero(T const &v) { return v == static_cast<T>(0); } |
|---|
| 45 | template<class T> inline bool is_neg (T const &v) { return v < static_cast<T>(0); } |
|---|
| 46 | template<class T> inline bool is_pos (T const &v) { return v > static_cast<T>(0); } |
|---|
| 47 | }</pre> |
|---|
| 48 | |
|---|
| 49 | <h3>Numeric limits</h3> |
|---|
| 50 | |
|---|
| 51 | <p>Another remark about the checking policy. It normally is powerful enough |
|---|
| 52 | to handle the exceptional behavior that the basic type could induce; in |
|---|
| 53 | particular infinite and invalid numbers (thanks to the four functions |
|---|
| 54 | <code>pos_inf</code>, <code>neg_inf</code>, <code>nan</code> and |
|---|
| 55 | <code>is_nan</code>). However, if you use |
|---|
| 56 | <code>interval_lib::checking_base</code> (and the default checking policy |
|---|
| 57 | uses it), your base type should have a correctly specialized |
|---|
| 58 | <code>std::numeric_limits<T></code>. In particular, the values |
|---|
| 59 | <code>has_infinity</code> and <code>has_quiet_NaN</code>, and the functions |
|---|
| 60 | <code>infinity</code> and <code>quiet_NaN</code> should be accordingly |
|---|
| 61 | defined.</p> |
|---|
| 62 | |
|---|
| 63 | <p>So, to summarize, if you do not rely on the default policy and do not use |
|---|
| 64 | <code>interval_lib::checking_base</code>, it is not necessary to have a |
|---|
| 65 | specialization of the numeric limits for your base type.</p> |
|---|
| 66 | |
|---|
| 67 | <h3>Mathematical properties</h3> |
|---|
| 68 | |
|---|
| 69 | <p>Ensuring the numbers are correctly ordered is not enough. The basic |
|---|
| 70 | operators should also respect some properties depending on the order. Here |
|---|
| 71 | they are:</p> |
|---|
| 72 | <ul> |
|---|
| 73 | <li>0 ≤ <i>x</x>⇒ -<i>x</i> ≤ 0</i></li> |
|---|
| 74 | <li><i>x</i> ≤ <i>y</i> ⇒ -<i>y</i> ≤ -<i>x</i></li> |
|---|
| 75 | <li><i>x</i> ≤ <i>y</i> ⇒ <i>x</i>+<i>z</i> ≤ |
|---|
| 76 | <i>y</i>+<i>z</i></li> |
|---|
| 77 | <li><i>x</i> ≤ <i>y</i> and <i>z</i> ≥ 0 ⇒ |
|---|
| 78 | <i>x</i>×<i>z</i> ≤ <i>y</i>×<i>z</i></li> |
|---|
| 79 | <li>0 < <i>x</i> ≤ <i>y</i> ⇒ 0 < 1/<i>y</i> ≤ |
|---|
| 80 | 1/<i>x</i></li> |
|---|
| 81 | </ul> |
|---|
| 82 | |
|---|
| 83 | <p>The previous properties are also used (and enough) for <code>abs</code>, |
|---|
| 84 | <code>square</code> and <code>pow</code>. For all the transcendental |
|---|
| 85 | functions (including <code>sqrt</code>), other properties are needed. These |
|---|
| 86 | functions should have the same properties than the corresponding real |
|---|
| 87 | functions. For example, the expected properties for <code>cos</code> are:</p> |
|---|
| 88 | <ul> |
|---|
| 89 | <li><code>cos</code> is defined for all the valid numbers;</li> |
|---|
| 90 | <li>it is 2π-periodic;</li> |
|---|
| 91 | <li><code>cos</code>(2π-<i>x</i>) is equal to |
|---|
| 92 | <code>cos</code>(<i>x</i>);</li> |
|---|
| 93 | <li><code>cos</code> is a decreasing function on [0,2π].</li> |
|---|
| 94 | </ul> |
|---|
| 95 | |
|---|
| 96 | <h3>Rounding</h3> |
|---|
| 97 | |
|---|
| 98 | <p>If you work with a base type and no inexact result is ever computed, you |
|---|
| 99 | can skip the rest of this paragraph. You can also skip it if you are not |
|---|
| 100 | interested in the inclusion property (if approximate results are enough). If |
|---|
| 101 | you are still reading, it is probably because you want to know the basic |
|---|
| 102 | properties the rounding policy should validate.</p> |
|---|
| 103 | |
|---|
| 104 | <p>Whichever operation or function you consider, the following property |
|---|
| 105 | should be respected: <code>f_down(x,y) <= f(x,y) <= f_up(x,y)</code>. |
|---|
| 106 | Here, <code>f</code> denotes the infinitely precise function computed and |
|---|
| 107 | <code>f_down</code> and <code>f_up</code> are functions which return possibly |
|---|
| 108 | inexact values but of the correct type (the base type). If possible, they |
|---|
| 109 | should try to return the nearest representable value, but it is not always |
|---|
| 110 | easy.</p> |
|---|
| 111 | |
|---|
| 112 | <h3>Constants</h3> |
|---|
| 113 | |
|---|
| 114 | <p>In order for the trigonometric functions to correctly work, the library |
|---|
| 115 | need to know the value of the π constant (and also π/2 and |
|---|
| 116 | 2π). Since these constants may not be representable in the base type, |
|---|
| 117 | the library does not have to know the exact value: a lower bound and an upper |
|---|
| 118 | bound are enough. If these values are not provided by the user, the default |
|---|
| 119 | values will be used: they are integer values (so π is bounded by 3 and |
|---|
| 120 | 4).</p> |
|---|
| 121 | |
|---|
| 122 | <h3>Operators and conversions</h3> |
|---|
| 123 | |
|---|
| 124 | <p>As explained at the beginning, the comparison operators should be defined |
|---|
| 125 | for the base type. The rounding policy defines a lot of functions used by the |
|---|
| 126 | interval library. So the arithmetic operators do not need to be defined for |
|---|
| 127 | the base type (unless required by one of the predefined classes). However, |
|---|
| 128 | there is an exception: the unary minus need to be defined. Moreover, this |
|---|
| 129 | operator should only provide exact results; it is the reason why the rounding |
|---|
| 130 | policy does not provide some negation functions.</p> |
|---|
| 131 | |
|---|
| 132 | <p>The conversion from <code>int</code> to the base type needs to be defined |
|---|
| 133 | (only a few values need to be available: -1, 0, 1, 2). The conversion the |
|---|
| 134 | other way around is provided by the rounding policy (<code>int_down</code> |
|---|
| 135 | and <code>int_up</code> members); and no other conversion is strictly needed. |
|---|
| 136 | However, it may be valuable to provide as much conversions as possible in the |
|---|
| 137 | rounding policy (<code>conv_down</code> and <code>conv_up</code> members) in |
|---|
| 138 | order to benefit from interval conversions.</p> |
|---|
| 139 | <hr> |
|---|
| 140 | |
|---|
| 141 | <p>Revised: 2004-02-17<br> |
|---|
| 142 | Copyright (c) Guillaume Melquiond, Sylvain Pion, Hervé Brönnimann, 2002. |
|---|
| 143 | Polytechnic University.<br> |
|---|
| 144 | Copyright (c) Guillaume Melquiond, 2004.</p> |
|---|
| 145 | </body> |
|---|
| 146 | </html> |
|---|
