[Boost-commit] svn:boost r67108 - trunk/libs/numeric/interval/doc

Subject: [Boost-commit] svn:boost r67108 - trunk/libs/numeric/interval/doc
From: steven_at_[hidden]
Date: 2010-12-08 12:45:33

Author: steven_watanabe
Date: 2010-12-08 12:45:32 EST (Wed, 08 Dec 2010)
New Revision: 67108
URL: http://svn.boost.org/trac/boost/changeset/67108

Log:
Apply patch to fix typos.  Fixes #4931.
Text files modified: 
   trunk/libs/numeric/interval/doc/guide.htm    |     2 +-                                      
   trunk/libs/numeric/interval/doc/interval.htm |    14 +++++++-------                          
   trunk/libs/numeric/interval/doc/rounding.htm |     4 ++--                                    
   trunk/libs/numeric/interval/doc/todo.htm     |     4 ++--                                    
   4 files changed, 12 insertions(+), 12 deletions(-)

Modified: trunk/libs/numeric/interval/doc/guide.htm
==============================================================================
--- trunk/libs/numeric/interval/doc/guide.htm	(original)
+++ trunk/libs/numeric/interval/doc/guide.htm	2010-12-08 12:45:32 EST (Wed, 08 Dec 2010)
@@ -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

Modified: trunk/libs/numeric/interval/doc/interval.htm
==============================================================================
--- trunk/libs/numeric/interval/doc/interval.htm	(original)
+++ trunk/libs/numeric/interval/doc/interval.htm	2010-12-08 12:45:32 EST (Wed, 08 Dec 2010)
@@ -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.</p>
+  property is no longer guaranteed.</p>
 
   <p>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
   <code>empty</code> and <code>whole</code> 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 <code>hull</code>. <code>empty</code> and
   <code>whole</code> involve the checking policy in order to get the bounds
@@ -566,7 +566,7 @@
   <p>The functions <code>division_part1</code> and
   <code>division_part2</code> 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 ]-&infin;,&infin;[ but the union
+  closed set containing [2,3] / [-2,1] is not ]-&infin;,&infin;[ but the union
   of ]-&infin;,-1] and [2,&infin;[. When the result of the division is
   representable by only one interval, <code>division_part1</code> returns
   this interval and sets the boolean reference to <code>false</code>.
@@ -808,7 +808,7 @@
 
   <h4>Comparisons</h4>
 
-  <p>One of the biggest problems is problably the correct use of the
+  <p>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 <code>x != x</code> is always true
@@ -831,7 +831,7 @@
   be equal: <code>x/x</code> and 1, <code>x*x</code> and
   <code>square(x)</code>, <code>x-x</code> 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, <code>square(x)-2*x</code> is far less precise than
   <code>square(x-1)-1</code>.</p>
@@ -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

Modified: trunk/libs/numeric/interval/doc/rounding.htm
==============================================================================
--- trunk/libs/numeric/interval/doc/rounding.htm	(original)
+++ trunk/libs/numeric/interval/doc/rounding.htm	2010-12-08 12:45:32 EST (Wed, 08 Dec 2010)
@@ -41,7 +41,7 @@
   <pre>
 /* 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.
   <a href="#extreg">Here</a> is an example of what happens when the rounding
   is not enforced.</p>

Modified: trunk/libs/numeric/interval/doc/todo.htm
==============================================================================
--- trunk/libs/numeric/interval/doc/todo.htm	(original)
+++ trunk/libs/numeric/interval/doc/todo.htm	2010-12-08 12:45:32 EST (Wed, 08 Dec 2010)
@@ -16,7 +16,7 @@
   <h2>Comments from the review process</h2>
 
   <ul>
-    <li>It would be nice to have a 100% portable Rouding policy class based
+    <li>It would be nice to have a 100% portable Rounding policy class based
     on LIA-1 only, with no additional requirement such as IEEE 754 or even
     more.</li>
 
@@ -42,7 +42,7 @@
     <li>Safe conversions from <code>interval&lt;double&gt;</code> to
     <code>interval&lt;float&gt;</code>? Requires partial specialization.</li>
 
-    <li>It would be nice to use the expression template mecanism to
+    <li>It would be nice to use the expression template mechanism to
     automatically use the more efficient unprotected rounding mode version
     for small subexpressions (although you can do bigger expressions by
     hand).</li>