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