[Boost-commit] svn:boost r41123 - sandbox/unordered/libs/unordered/doc

From: daniel_james_at_[hidden]
Date: 2007-11-15 18:36:35

Author: danieljames
Date: 2007-11-15 18:36:33 EST (Thu, 15 Nov 2007)
New Revision: 41123
URL: http://svn.boost.org/trac/boost/changeset/41123

Log:
Spell check the unordered container quickbook files.

Text files modified: 
   sandbox/unordered/libs/unordered/doc/buckets.qbk       |     2 +-                                      
   sandbox/unordered/libs/unordered/doc/comparison.qbk    |    10 +++++-----                              
   sandbox/unordered/libs/unordered/doc/hash_equality.qbk |     2 +-                                      
   sandbox/unordered/libs/unordered/doc/intro.qbk         |     2 +-                                      
   sandbox/unordered/libs/unordered/doc/rationale.qbk     |    14 +++++++-------                          
   5 files changed, 15 insertions(+), 15 deletions(-)

Modified: sandbox/unordered/libs/unordered/doc/buckets.qbk
==============================================================================
--- sandbox/unordered/libs/unordered/doc/buckets.qbk	(original)
+++ sandbox/unordered/libs/unordered/doc/buckets.qbk	2007-11-15 18:36:33 EST (Thu, 15 Nov 2007)
@@ -14,7 +14,7 @@
 
 In order to decide which bucket to place an element in, the container applies
 the hash function, `Hash`, to the element's key (for `unordered_set` and
-`unordered_multiset` the key is the whole element, but is refered to as the key
+`unordered_multiset` the key is the whole element, but is referred to as the key
 so that the same terminology can be used for sets and maps). This returns a
 value of type `std::size_t`.  `std::size_t` has a much greater range of values
 then the number of buckets, so that container applies another transformation to

Modified: sandbox/unordered/libs/unordered/doc/comparison.qbk
==============================================================================
--- sandbox/unordered/libs/unordered/doc/comparison.qbk	(original)
+++ sandbox/unordered/libs/unordered/doc/comparison.qbk	2007-11-15 18:36:33 EST (Thu, 15 Nov 2007)
@@ -8,8 +8,8 @@
     [[Associative Containers] [Unordered Associative Containers]]
 
     [
-        [Parameterized by an ordering relation `Compare`]
-        [Parameterized by a function object `Hash` and an equivalence relation
+        [Parametrised by an ordering relation `Compare`]
+        [Parametrised by a function object `Hash` and an equivalence relation
             `Pred`]
     ]
     [
@@ -51,7 +51,7 @@
             element can be inserted into a different bucket.]
     ]
     [
-        [`iterator`, `const_iterator` are of the biderctional category.]
+        [`iterator`, `const_iterator` are of the bidirectional category.]
         [`iterator`, `const_iterator` are of at least the forward category.]
     ]
     [
@@ -108,7 +108,7 @@
     ]
     [
         [Insert a single element with a hint]
-        [Amortized constant if t elements inserted right after hint,
+        [Amortised constant if t elements inserted right after hint,
             logarithmic otherwise]
         [Average case constant, worst case linear (ie. the same as
             a normal insert).]
@@ -125,7 +125,7 @@
     ]
     [
         [Erase a single element by iterator]
-        [Amortized constant]
+        [Amortised constant]
         [Average case: O(1), Worst case: O(`size()`)]
     ]
     [

Modified: sandbox/unordered/libs/unordered/doc/hash_equality.qbk
==============================================================================
--- sandbox/unordered/libs/unordered/doc/hash_equality.qbk	(original)
+++ sandbox/unordered/libs/unordered/doc/hash_equality.qbk	2007-11-15 18:36:33 EST (Thu, 15 Nov 2007)
@@ -68,7 +68,7 @@
     boost::unordered_multiset<point, std::equal_to<point>, point_hash>
         points;
 
-Although, customizing Boost.Hash is probably a better solution:
+Although, customising Boost.Hash is probably a better solution:
 
     struct point {
         int x;

Modified: sandbox/unordered/libs/unordered/doc/intro.qbk
==============================================================================
--- sandbox/unordered/libs/unordered/doc/intro.qbk	(original)
+++ sandbox/unordered/libs/unordered/doc/intro.qbk	2007-11-15 18:36:33 EST (Thu, 15 Nov 2007)
@@ -28,7 +28,7 @@
 
 Also, the existing containers require a 'less than' comparison object
 to order their elements. For some data types this is impossible to implement
-or isn't practicle. For a hash table you need an equality function
+or isn't practical. For a hash table you need an equality function
 and a hash function for the key.
 
 So the __tr1__ introduced the unordered associative containers, which are

Modified: sandbox/unordered/libs/unordered/doc/rationale.qbk
==============================================================================
--- sandbox/unordered/libs/unordered/doc/rationale.qbk	(original)
+++ sandbox/unordered/libs/unordered/doc/rationale.qbk	2007-11-15 18:36:33 EST (Thu, 15 Nov 2007)
@@ -16,7 +16,7 @@
 
 The intent of this library is to implement the unordered
 containers in the draft standard, so the interface was fixed. But there are
-still some implementation desicions to make. The priorities are
+still some implementation decisions to make. The priorities are
 conformance to the standard and portability.
 
 The [@http://en.wikipedia.org/wiki/Hash_table wikipedia article on hash tables]
@@ -46,7 +46,7 @@
   standard requires that it is initially set to 1.0.
 
 * And since the standard is written with a eye towards chained
-  addressing, users will be suprised if the performance doesn't reflect that.
+  addressing, users will be surprised if the performance doesn't reflect that.
 
 So chained addressing is used.
 
@@ -76,9 +76,9 @@
 table. One is to have a prime number of buckets, another is to use a power
 of 2.
 
-Using a prime number of buckets, and choosing a bucket by using the modulous
-of the hash functions's result will usually give a good result. The downside
-is that the required modulous operation is fairly expensive.
+Using a prime number of buckets, and choosing a bucket by using the modulus
+of the hash function's result will usually give a good result. The downside
+is that the required modulus operation is fairly expensive.
 
 Using a power of 2 allows for much quicker selection of the bucket
 to use, but at the expense of loosing the upper bits of the hash value.
@@ -91,7 +91,7 @@
 knowledge of the number of bits in the hash value, so it isn't portable enough.
 This leaves more expensive methods, such as Knuth's Multiplicative Method
 (mentioned in Wang's article). These don't tend to work as well as taking the
-modulous of a prime, and the extra computation required might negate
+modulus of a prime, and the extra computation required might negate
 efficiency advantage of power of 2 hash tables.
 
 So, this implementation uses a prime number for the hash table size.
@@ -117,7 +117,7 @@
 no guarantee what state the allocators will be in. The only solution seems to
 be to double buffer the allocators. But I'm assuming that it won't throw for now.
 
-Update: The comittee have now decided that `swap` should do a fast swap if the
+Update: The committee have now decided that `swap` should do a fast swap if the
 allocator is Swappable and a slow swap using copy construction otherwise. To
 make this distinction requires concepts. For now I'm sticking with the current
 implementation.