
BoostCommit : 
Subject: [Boostcommit] svn:boost r67108  trunk/libs/numeric/interval/doc
From: steven_at_[hidden]
Date: 20101208 12:45:33
Author: steven_watanabe
Date: 20101208 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 20101208 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 20101208 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 ]∞,∞[ 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, <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>xx</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(x1)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 speedup 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 20101208 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 20101208 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 LIA1 only, with no additional requirement such as IEEE 754 or even
more.</li>
@@ 42,7 +42,7 @@
<li>Safe conversions from <code>interval<double></code> to
<code>interval<float></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>
BoostCommit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk