散列表大小是否取决于密钥的长度？

Question

我所知道的，

1. 哈希表大小取决于负载系数。
2. 它必须是最大素数，并使用该素数作为 散列函数中的模数值。
3. 素数不能太接近2的幂和10的幂。

我怀疑，

1. 散列表的大小是否取决于密钥的长度？

以下“Cormen算法简介”中的段落。 n = 2000是否意味着字符串的长度或将存储在哈希表中的元素数量？

  

m的良好值是不太接近2的精确幂的素数   例如，假设我们希望分配一个带有冲突的哈希表   通过链接解决，大约持有n = 2000个字符串，   其中一个字符有8位。我们不介意平均检查3   在不成功的搜索中的元素，所以我们分配一个哈希表   大小m = 701.选择数字701是因为它是接近=的素数   2000/3但不接近任何2的幂。将每个键k作为整数处理，   我们的哈希函数是

     

h（k）= k mod 701。

有人可以解释一下＆gt;

Answer 1

以下是使用哈希表进行权衡的概述。 假设您有一个带有m存储桶的哈希表，其中链存储了总共n个对象。

如果仅存储对象的引用，则消耗的总内存为O (m + n)。

现在，假设对于普通对象，其大小为s，计算其哈希值需要O (s)次，而O (s)则需要比较两个此类对象。 考虑检查哈希表中是否存在对象的操作。 该存储桶平均有n / m个元素，因此操作将花费O (s n / m)时间。

因此，权衡如下：当您增加桶m的数量时，会增加内存消耗，但会减少单个操作的平均时间。

对于原始问题 - 散列表的大小是否取决于密钥的长度？ - 不，它不应该，至少不是直接的。

您引用的段落仅提到字符串作为存储在哈希表中的对象的示例。 提到的一个属性是它们是8位字符串。 另一个是＆＃34; 我们不介意在不成功的搜索中检查平均3个元素＆＃34;。 并且它将存储对象的属性包装成表单：我们希望在一个存储桶中放置多少个元素？ 字符串本身的长度在任何地方都没有提到。

Answer 2

（2）和（3）是假的。只要使用正确的哈希函数，常见的是具有2^n桶（ref）的哈希表。在（1）中，哈希表占用的内存等于桶的数量乘以密钥的长度。请注意，对于字符串键，我们通常会保留指向字符串的指针，而不是字符串本身，因此键的长度是指针的长度，在64位计算机上为8个字节。

Answer 3

算法明智，不！ 钥匙的长度在这里无关紧要。 此外，钥匙本身并不重要，重要的是你预测的不同钥匙的数量。

实施明智，是的！由于您必须将密钥本身保存在哈希表中，因此它会反映其大小。

对于你的第二个问题，＆＃39; n＆＃39;表示要保留的不同键的数量。