Update the unordered rationale.

I just noticed that it wan't updated for the changes on 64 bit platforms.
Not very good, but I don't want to spend too long on this.  I'm tempted to just
delete it.

[SVN r86608]

doc/rationale.qbk

@@ -85,7 +85,8 @@ of 2.
 
 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.
+is that the required modulus operation is fairly expensive. This is what the
+containers do in most cases.
 
 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.
@@ -95,12 +96,16 @@ functions this can't be relied on.
 
 To avoid this a transformation could be applied to the hash function, for an
 example see __wang__.  Unfortunately, a transformation like Wang's requires
-knowledge of the number of bits in the hash value, so it isn't portable enough.
+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
+to use as a default. It can applicable in certain cases so the containers
-(mentioned in Wang's article). These don't tend to work as well as taking the
+have a policy based implementation that can use this alternative technique.
-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.
+Currently this is only done on 64 bit architecures, where prime number
+modulus can be expensive. Although this varies depending on the architecture,
+so I probably should revisit it.
+
+I'm also thinking of introducing a mechanism whereby a hash function can
+indicate that it's safe to be used directly with power of 2 buckets, in
+which case a faster plain power of 2 implementation can be used.
 
 [endsect]