Ticket #4931: boost-interval-typos.patch
| File boost-interval-typos.patch, 6.6 KB (added by , 12 years ago) |
|---|
-
libs/numeric/interval/doc/guide.htm
71 71 not really interested by the inclusion property; you are only interested by 72 72 the computation algorithms the library provides. So you do not need to use 73 73 any rounding; the checking also may not be useful. Use an "exact 74 computation" rounding (you are allowed to think the name st angely applies74 computation" rounding (you are allowed to think the name strangely applies 75 75 to the situation) and a checking that never tests for any invalid numbers 76 76 or empty intervals. By doing that, you will obtain library functions 77 77 reduced to their minimum (an addition of two intervals will only be two -
libs/numeric/interval/doc/interval.htm
146 146 methods (for instance, toward minus or plus infinity) if we want to 147 147 guarantee the inclusion property. Note that we also may explicitely specify 148 148 no rounding, for instance if the base number type is exact, i.e. the result 149 of a mathematic operation is always computed and represented without loss149 of a mathematical operation is always computed and represented without loss 150 150 of precision. If the number type is not exact, we may still explicitely 151 151 specify no rounding, with the obvious consequence that the inclusion 152 property is no long uer guaranteed.</p>152 property is no longer guaranteed.</p> 153 153 154 154 <p>Finally, because heavy loss of precision is always possible, some 155 155 numbers have to represent infinities or an exceptional behavior must be … … 480 480 set of values the intervals contain. E.g. with the default policies, 481 481 intervals are subsets of the set of real numbers. The static functions 482 482 <code>empty</code> and <code>whole</code> produce the intervals/subsets 483 that are re pectively the empty subset and the whole set. They are static483 that are respectively the empty subset and the whole set. They are static 484 484 member functions rather than global functions because they cannot guess 485 485 their return types. Likewise for <code>hull</code>. <code>empty</code> and 486 486 <code>whole</code> involve the checking policy in order to get the bounds … … 566 566 <p>The functions <code>division_part1</code> and 567 567 <code>division_part2</code> are useful when the user expects the division 568 568 to return disjoint intervals if necessary. For example, the narrowest 569 closed set contain g [2,3] / [-2,1] is not ]-∞,∞[ but the union569 closed set containing [2,3] / [-2,1] is not ]-∞,∞[ but the union 570 570 of ]-∞,-1] and [2,∞[. When the result of the division is 571 571 representable by only one interval, <code>division_part1</code> returns 572 572 this interval and sets the boolean reference to <code>false</code>. … … 808 808 809 809 <h4>Comparisons</h4> 810 810 811 <p>One of the biggest problems is prob lably the correct use of the811 <p>One of the biggest problems is probably the correct use of the 812 812 comparison functions and operators. First, functions and operators do not 813 813 try to know if two intervals are the same mathematical object. So, if the 814 814 comparison used is "certain", then <code>x != x</code> is always true … … 831 831 be equal: <code>x/x</code> and 1, <code>x*x</code> and 832 832 <code>square(x)</code>, <code>x-x</code> and 0, etc. So the main cause of 833 833 wide intervals is that interval arithmetic does not identify different 834 occur ences of the same variable. So, whenever possible, the user has to834 occurrences of the same variable. So, whenever possible, the user has to 835 835 rewrite the formulas to eliminate multiple occurences of the same variable. 836 836 For example, <code>square(x)-2*x</code> is far less precise than 837 837 <code>square(x-1)-1</code>.</p> … … 884 884 implementations of the rounding policy for the primitive types float and 885 885 double. In order for these implementations to be correct and fast, the 886 886 library needs to work a lot with rounding modes. Some processors are 887 directly dealt with and some mec anisms are provided in order to speed up887 directly dealt with and some mechanisms are provided in order to speed up 888 888 the computations. It seems to be heavy and hazardous optimizations for a 889 889 gain of only a few computer cycles; but in reality, the speed-up factor can 890 890 easily go past 2 or 3 depending on the computer. Moreover, these -
libs/numeric/interval/doc/rounding.htm
41 41 <pre> 42 42 /* Rounding requirements */ 43 43 struct rounding { 44 // defau t constructor, destructor44 // default constructor, destructor 45 45 rounding(); 46 46 ~rounding(); 47 47 // mathematical operations … … 375 375 argument correctly rounded accordingly to the current rounding mode if it 376 376 was not already the case. This function is necessary to handle delayed 377 377 rounding. Indeed, depending on the way the computations are done, the 378 intermediate results may be internal y stored in a more precise format and378 intermediate results may be internally stored in a more precise format and 379 379 it can lead to a wrong rounding. So the function enforces the rounding. 380 380 <a href="#extreg">Here</a> is an example of what happens when the rounding 381 381 is not enforced.</p> -
libs/numeric/interval/doc/todo.htm
16 16 <h2>Comments from the review process</h2> 17 17 18 18 <ul> 19 <li>It would be nice to have a 100% portable Rou ding policy class based19 <li>It would be nice to have a 100% portable Rounding policy class based 20 20 on LIA-1 only, with no additional requirement such as IEEE 754 or even 21 21 more.</li> 22 22 … … 42 42 <li>Safe conversions from <code>interval<double></code> to 43 43 <code>interval<float></code>? Requires partial specialization.</li> 44 44 45 <li>It would be nice to use the expression template mec anism to45 <li>It would be nice to use the expression template mechanism to 46 46 automatically use the more efficient unprotected rounding mode version 47 47 for small subexpressions (although you can do bigger expressions by 48 48 hand).</li>
