Index: libs/numeric/interval/doc/guide.htm =================================================================== --- libs/numeric/interval/doc/guide.htm (revision 67019) +++ libs/numeric/interval/doc/guide.htm (working copy) @@ -71,7 +71,7 @@ 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 stangely applies + 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 Index: libs/numeric/interval/doc/interval.htm =================================================================== --- libs/numeric/interval/doc/interval.htm (revision 67019) +++ libs/numeric/interval/doc/interval.htm (working copy) @@ -146,10 +146,10 @@ methods (for instance, toward minus or plus infinity) if we want to guarantee the inclusion property. Note that we also may explicitely specify no rounding, for instance if the base number type is exact, i.e. the result - of a mathematic operation is always computed and represented without loss + of a mathematical operation is always computed and represented without loss of precision. If the number type is not exact, we may still explicitely specify no rounding, with the obvious consequence that the inclusion - property is no longuer guaranteed.

+ property is no longer guaranteed.

Finally, because heavy loss of precision is always possible, some numbers have to represent infinities or an exceptional behavior must be @@ -480,7 +480,7 @@ set of values the intervals contain. E.g. with the default policies, intervals are subsets of the set of real numbers. The static functions empty and whole produce the intervals/subsets - that are repectively the empty subset and the whole set. They are static + that are respectively the empty subset and the whole set. They are static member functions rather than global functions because they cannot guess their return types. Likewise for hull. empty and whole involve the checking policy in order to get the bounds @@ -566,7 +566,7 @@

The functions division_part1 and division_part2 are useful when the user expects the division to return disjoint intervals if necessary. For example, the narrowest - closed set containg [2,3] / [-2,1] is not ]-∞,∞[ but the union + closed set containing [2,3] / [-2,1] is not ]-∞,∞[ but the union of ]-∞,-1] and [2,∞[. When the result of the division is representable by only one interval, division_part1 returns this interval and sets the boolean reference to false. @@ -808,7 +808,7 @@

Comparisons

-

One of the biggest problems is problably the correct use of the +

One of the biggest problems is probably the correct use of the comparison functions and operators. First, functions and operators do not try to know if two intervals are the same mathematical object. So, if the comparison used is "certain", then x != x is always true @@ -831,7 +831,7 @@ be equal: x/x and 1, x*x and square(x), x-x and 0, etc. So the main cause of wide intervals is that interval arithmetic does not identify different - occurences of the same variable. So, whenever possible, the user has to + occurrences of the same variable. So, whenever possible, the user has to rewrite the formulas to eliminate multiple occurences of the same variable. For example, square(x)-2*x is far less precise than square(x-1)-1.

@@ -884,7 +884,7 @@ implementations of the rounding policy for the primitive types float and double. In order for these implementations to be correct and fast, the library needs to work a lot with rounding modes. Some processors are - directly dealt with and some mecanisms are provided in order to speed up + directly dealt with and some mechanisms are provided in order to speed up the computations. It seems to be heavy and hazardous optimizations for a gain of only a few computer cycles; but in reality, the speed-up factor can easily go past 2 or 3 depending on the computer. Moreover, these Index: libs/numeric/interval/doc/rounding.htm =================================================================== --- libs/numeric/interval/doc/rounding.htm (revision 67019) +++ libs/numeric/interval/doc/rounding.htm (working copy) @@ -41,7 +41,7 @@ 
 /* Rounding requirements */
 struct rounding {
-  // defaut constructor, destructor
+  // default constructor, destructor
   rounding();
   ~rounding();
   // mathematical operations
@@ -375,7 +375,7 @@
   argument correctly rounded accordingly to the current rounding mode if it
   was not already the case. This function is necessary to handle delayed
   rounding. Indeed, depending on the way the computations are done, the
-  intermediate results may be internaly stored in a more precise format and
+  intermediate results may be internally stored in a more precise format and
   it can lead to a wrong rounding. So the function enforces the rounding.
   Here is an example of what happens when the rounding
   is not enforced.

Index: libs/numeric/interval/doc/todo.htm
===================================================================
--- libs/numeric/interval/doc/todo.htm	(revision 67019)
+++ libs/numeric/interval/doc/todo.htm	(working copy)
@@ -16,7 +16,7 @@
   
Comments from the review process