Fix errata

doc/checking.htm

@@ -22,10 +22,10 @@ <h1>Checking policies</h1>
   is a NaN). What to do in such a case? First, we could say that the second
   argument can never be an invalid number. Second, we could also say such a
   situation can arise but is forbidden. Third, we could allow such values and
-  generate an empty interval when encountered. And there is many other
+  generate an empty interval when encountered. And there are many other
   possibilities.</p>
 
-  <p>It is the reason why such a policy is used: there is a lot of
+  <p>It is the reason why such a policy is used: there are a lot of
   interesting behaviors and it would be sad to arbitrarily select one of
   these.</p>
 
@@ -56,27 +56,27 @@ <h2>Requirements</h2>
   value, such a value can be used.</p>
 
   <p>Next comes <code>nan</code>. This function is used each time a function
-  need to return a value of type <code>T</code> but is unable to compute it.
+  needs to return a value of type <code>T</code> but is unable to compute it.
   It only happens when one of the arguments of the function is invalid. For
   example, if you ask what the median value of an empty interval is,
   <code>nan</code> will be used. But please remember: <code>lower</code> and
   <code>upper</code> directly return the value stocked in the interval; so,
   if the interval is empty, <code>lower</code> will not answer
   <code>by</code> a call to <code>checking::nan</code> (but will return the
-  same value than <code>checking::empty_lower</code> could return).</p>
+  same value as <code>checking::empty_lower</code> could return).</p>
 
   <p><code>empty_lower</code> and <code>empty_upper</code> respectively
   return the lower and upper bound of the empty interval. There is no
-  requirements for <code>empty_lower</code> and <code>empty_upper</code> to
-  return the same value than <code>checking::nan</code>. For example, if the
+  requirement for <code>empty_lower</code> and <code>empty_upper</code> to
+  return the same value as <code>checking::nan</code>. For example, if the
   type <code>T</code> does not have any invalid value, the
   <code>empty_</code> functions can return the [1;0] interval.</p>
 
   <p><code>is_nan</code> is used to test if a value of type <code>T</code> is
   invalid or not. <code>is_empty</code> tests if the interval formed by the
   two arguments is empty or not. Such tests will generally be at the
   beginning of each function which involves an argument of type
-  <code>T</code>. If one of the inputs is declared invalid, the the function
+  <code>T</code>. If one of the inputs is declared invalid, the function
   will try to produce an invalid value or an input interval.</p>
 
   <h2>Synopsis</h2>
@@ -115,10 +115,10 @@ <h2>Predefined classes</h2>
   <code>empty_upper</code>; and a basic test is used for <code>is_nan</code>
   (it is <code>x!=x</code>). If <code>T</code> does not have quiet NaNs, then
   <code>nan</code> is an <code>assert(false)</code>, the empty interval is
-  [1,0], and <code>is_nan</code> always return <code>false</code>. As for
+  [1,0], and <code>is_nan</code> always returns <code>false</code>. As for
   <code>nan</code>, <code>pos_inf</code> returns
   <code>numeric_limits::infinity()</code> if possible, or is an
-  <code>assert(false</code>) otherwise. <code>neg_inf</code> returns the
+  <code>assert(false)</code> otherwise. <code>neg_inf</code> returns the
   opposite. Finally, <code>is_empty(T l,T u)</code> is always defined by
   <code>!(l&lt;=u)</code>.</p>
 
@@ -171,7 +171,7 @@ <h2>Customizing your own checking policy</h2>
   the conversion at the first encountered problem. So
   <code>empty_lower</code> and <code>empty_upper</code> need to return
   suitable values in order to define an empty interval (you can use an upper
-  bound which is not greater or equal than the lower bound for example); and
+  bound which is not greater or equal to the lower bound for example); and
   <code>is_empty</code> must be able to distinguish empty intervals from the
   valid intervals.</p>
 
@@ -227,7 +227,7 @@ <h2>Some examples</h2>
     <li>If you do not mind having undefined results when an empty interval or
     an interval number is produced, your best bet is to create your own
     policy by overloading <code>checking_base</code> and modifying
-    <code>is_nan</code> et <code>is_empty</code> in order for them to always
+    <code>is_nan</code> and <code>is_empty</code> in order for them to always
     return <code>false</code>. It is probably the fastest checking policy
     available; however, it suffers from its deficient security.</li>
   </ul>

doc/comparisons.htm

@@ -14,14 +14,14 @@
   <h1>Comparisons</h1>
 
   <p>As was said before, the definition of the comparison operators induces a
-  slight problem. There are many ways to define them, depending of the return
+  slight problem. There are many ways to define them, depending on the return
   type or the expected order. It is the reason why the meaning of the
   operators is not fixed once and for all.</p>
 
   <p>The way the operators are defined could have been influenced by a
   policy, as it is already the case for the rounding and the checking.
-  However, comparisons are more an external property of the the class rather
-  than an internal one. They are meant to be locally modified, independantly
+  However, comparisons are more an external property of the class rather
+  than an internal one. They are meant to be locally modified, independently
   of the type of the intervals.</p>
 
   <p>The operators <code>&lt;</code>, <code>&lt;=</code>, <code>&gt;</code>,
@@ -30,7 +30,7 @@ <h1>Comparisons</h1>
   type. However, due to technical limitations, this base type can only be the
   second argument; so the operators are unfortunately not fully symmetric.
   The return type is not always <code>bool</code>, since some interesting
-  results can be achieved by using a tri-state return type. So here is the
+  results can be achieved by using a tri-state return type. So here are the
   common signatures of the operators:</p>
   <pre>
 template&lt;class T, class Policies1, class Policies2&gt;
@@ -44,9 +44,9 @@ <h2>vided comparisons</h2>
 
   <h3>Default comparison</h3>
 
-  <p>If nothing is specified, the meaning of the comparison operators are an
+  <p>If nothing is specified, the meaning of the comparison operators is an
   extension of the operator on the base type. More precisely, if one of the
-  argument is invalid or empty, an exception is thrown. If the arguments are
+  arguments is invalid or empty, an exception is thrown. If the arguments are
   valid, the following rules are applied to determine the result of
   [<i>a</i>,<i>b</i>] <code>op</code> [<i>c</i>,<i>d</i>] (just consider
   <i>c</i> <code>==</code> <i>d</i> if the second argument is of type
@@ -55,11 +55,11 @@ <h3>Default comparison</h3>
   <ul>
     <li>if &forall; <i>x</i> &isin; [<i>a</i>,<i>b</i>] &forall; <i>y</i>
     &isin; [<i>c</i>,<i>d</i>] <code>(</code><i>x</i> <code>op</code>
-    y<code>)</code>, then <code>true</code></li>
+    <i>y</i><code>)</code>, then <code>true</code></li>
 
     <li>if &forall; <i>x</i> &isin; [<i>a</i>,<i>b</i>] &forall; <i>y</i>
     &isin; [<i>c</i>,<i>d</i>] <code>!(</code><i>x</i> <code>op</code>
-    y<code>)</code>, then <code>false</code></li>
+    <i>y</i><code>)</code>, then <code>false</code></li>
 
     <li>otherwise throw an exception.</li>
   </ul>
@@ -107,7 +107,7 @@ <h3>Other comparisons</h3>
   their respective header files under
   <code>&lt;boost/numeric/interval/compare/...&gt;</code>. And as for the
   default comparison, the operators will generally complain by throwing an
-  exception if feed by invalid values.</p>
+  exception if fed by invalid values.</p>
 
   <ul>
     <li><code>certain</code>: this comparison is equivalent to the default
@@ -122,7 +122,7 @@ <h3>Other comparisons</h3>
     <li><code>lexicographic</code>: the lexicographic order (the lower bounds
     are first compared, and if it is not enough to know the result, the upper
     bounds are then compared). This order does not have a meaning in interval
-    arithmetic. However, since it is the natural total order on pair of
+    arithmetic. However, since it is the natural total order on pairs of
     (totally ordered) numbers, it may be handy in some cases.</li>
 
     <li><code>set</code>: the set inclusion partial order. This time, an

doc/examples.htm

@@ -17,7 +17,7 @@ <h2>A first example</h2>
 
   <p>This example shows how to design a function which takes a polynomial and
   a value and returns the sign of this polynomial at this point. This
-  function is a filter: if the answer is not guaranteed, the functions says
+  function is a filter: if the answer is not guaranteed, the function says
   so. The reason of using a filter rather than a simple evaluation function
   is: computations with floating-point numbers will incur approximations and
   it can be enough to change the sign of the polynomial. So, in order to
@@ -107,7 +107,7 @@ <h2>Other tests and examples</h2>
 
   <p>In <code>libs/numeric/interval/test/</code> and
   <code>libs/numeric/interval/examples/</code> are some test and example
-  programs.. The examples illustrate a few uses of intervals. For a general
+  programs. The examples illustrate a few uses of intervals. For a general
   description and considerations on using this library, and some potential
   domains of application, please read this <a href=
   "guide.htm">mini-guide</a>.</p>
@@ -178,8 +178,8 @@ <h2>Examples</h2>
   operations for a whole function (which computes the value of a polynomial
   by using Horner scheme).</p>
 
-  <p><b>io.cpp</b> shows some stream input and output operators for intervals
-  .The wide variety of possibilities explains why the library do not
+  <p><b>io.cpp</b> shows some stream input and output operators for intervals.
+  The wide variety of possibilities explains why the library does not
   implement i/o operators and they are left to the user.</p>
 
   <p><b>newton-raphson.cpp</b> is an implementation of a specialized version

doc/guide.htm

@@ -13,14 +13,14 @@
 <body lang="en">
   <h1>Choosing Your Own Interval Type</h1>
 
-  <p>First of all, you need to select your base type. In order to obtain an
+  <p>First of all, you need to select your base type. In order to obtain a
   useful interval type, the numbers should respect some requirements. Please
   refer to <a href="numbers.htm">this page</a> in order to see them. When
   your base type is robust enough, you can go to the next step: the choice of
   the policies.</p>
 
   <p>As you should already know if you did not come to this page by accident,
-  the <code>interval</code> class expect a policies argument describing the
+  the <code>interval</code> class expects a policies argument describing the
   <a href="rounding.htm">rounding</a> and <a href="checking.htm">checking</a>
   policies. The first thing to do is to verify if the default policies are or
   are not adapted to your case. If your base type is not <code>float</code>,
@@ -31,7 +31,7 @@ <h1>Choosing Your Own Interval Type</h1>
 
   <p>The default policies define an interval type that performs precise
   computations (for <code>float</code>, <code>double</code>, <code>long
-  double</code>), detects invalid numbers and throws exception each times an
+  double</code>), detects invalid numbers and throws an exception each times an
   empty interval is created. This is a brief description and you should refer
   to the corresponding sections for a more precise description of the default
   policies. Unless you need some special behavior, this default type is
@@ -51,12 +51,12 @@ <h3>Solving systems</h3>
   <code>boost::interval&lt;double&gt;</code> is probably what you need. The
   computations are precise, and they may be fast if enclosed in a protected
   rounding mode block (see the <a href="rounding.htm#perf">performance</a>
-  section). The comparison are "certain"; it is probably the most used type
+  section). The comparisons are "certain"; it is probably the most used type
   of comparison, and the other comparisons are still accessible by the
-  explicit comparison functions. The checking forbid empty interval; they are
-  not needed since there would be an empty interval at end of the computation
+  explicit comparison functions. The checking forbids empty intervals; they are
+  not needed since there would be an empty interval at the end of the computation
   if an empty interval is created during the computation, and no root would
-  be inside. The checking also forbid invalid numbers (NaN for floating-point
+  be inside. The checking also forbids invalid numbers (NaN for floating-point
   numbers). It can be a minor performance hit if you only use exact
   floating-point constants (which are clearly not NaNs); however, if
   performance really does matter, you will probably use a good compiler which
@@ -101,7 +101,7 @@ <h3>Switching interval types</h3>
   the computations; it is a change of the rounding policy. It also happens
   when you want to temporarily allow empty intervals to be created; it is a
   change of the checking policy. These changes should not be prohibited: they
-  can greatly enhance a program (lisibility, interest, performance).</p>
+  can greatly enhance a program (legibility, interest, performance).</p>
   <hr>
 
   <p><a href="http://validator.w3.org/check?uri=referer"><img border="0" src=

doc/includes.htm

@@ -193,7 +193,7 @@ <h3><code>interval/ext/integer.hpp</code></h3>
 
   <h3><code>interval/ext/x86_fast_rounding_control.hpp</code></h3>
 
-  <p>This header defines a new rounding policy allowing to workaround the
+  <p>This header defines a new rounding policy allowing to work around the
   precision problem of the x86 processors (and so speeding up the
   computations). However, it only is a partial solution and it shouldn't be
   used when there is a possibility of underflow or overflow.</p>