深蓝色的空间

Hash Table（哈希表）就是根据对象的特征进行定位的一种数据结构。一个简单的实现方法是将对象通过某种运算得到一个整数，再让这个整数除以哈希表的大小，取其余数，以此作为对象的存储位置。
很多的书上认为，哈希表的大小最好是选择一个大的质数，并且最好不要和2的整数幂接近。《算法导论》上还认为，最不好的选择是哈希表的大小恰好是2的整数幂，对此的解释是（只记得大意）：因为计算机是用二进制存储的，当一个二进制数除以一个2的整数幂的时候，结果就是这个二进制数的后几位，前面的位都丢失了，也就意味着丢失了一部分信息，进而导致哈希表中的元素分布不均匀。
这个解释看似合理，但我不认同。不光是我，Java开发小组的人也不认同。Java里的HashSet类偏偏就把哈希表的大小设置成2的整数幂。可以设想一下，对于自然数集合中的任意一个数x，对于一个正整数M，难道x mod M为某些值的概率会大些吗？显然不是，因为x是在自然数集合里任选的，当选取的次数非常多时，x mod M的结果应该是平均分布在[0,M-1]中。我认为《算法导论》的错误在于先引入了二进制，其实二进制和哈希表的“碰撞”根本没有什么关系；然后说对除以2^n的余数会丢失位，丢失信息，这显然也不对，因为只要x>=M，x mod M的结果总是要“丢失一些信息的”。照《算法导论》的说法，如果计算机采用十进制，那哈希表的容量是10^n的话岂不是很糟？这种解释显然站不住脚。
我认为对于x mod M这样的哈希函数来说，好坏应该取决于x的生成方式和M的值。比如一个字符串“ABC”，如果我让x("ABC")=65*128^2+66*128+67，即把字符串当成一个128进制的整数，那么若M=128，那就很糟糕了。因为这样无论是什么字符串，最终结果只取决于最后一个字符，这才会造成分布不均匀。

以上只是我个人的见解，有不妥之处欢迎指出。