哈希表的大小是否取决于键的长度？答案

【问题标题】：Does hashtable size depends upon length of key?哈希表的大小是否取决于键的长度？
【发布时间】：2016-11-28 17:58:49
【问题描述】：

我知道的，

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

我怀疑，

哈希表的大小是否取决于键的长度？

以下段落来自 Cormen 的《算法简介》一书。 n=2000 是指字符串的长度还是要存储在哈希表中的元素个数？

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

h(k) = k mod 701 .

谁能解释一下>

【问题讨论】：

“大小”是什么意思？桶数？平均每个桶的元素数？平均链长？与表相关的“一切”在 RAM 中使用的字节数？
我不懂你。我问“你所说的'大小'是什么意思”，显然是关于你的问题“......的大小”并且你回答“密钥的长度”......不计算。
simple size=桶数和桶数取决于给定字符串键的长度:)
不，为什么会这样？老实说，也许你最好只玩一个小例子（用笔和纸），看看会发生什么。看起来你有点沉迷于理论的东西。 ;)
哈希表大小实际上不需要是素数或远离二的幂。大多数常见的实现都是这样做的，但理论上并不是严格要求的。

标签： algorithm hashtable

【解决方案1】：

(2) 和 (3) 是错误的。只要您使用正确的散列函数，带有2^n 存储桶 (ref) 的散列表很常见。在 (1) 上，哈希表占用的内存等于桶数乘以键的长度。请注意，对于字符串键，我们通常保留指向字符串的指针，而不是字符串本身，因此键的长度是指针的长度，在 64 位机器上为 8 个字节。

【讨论】：

你能解释一下吗？n=2000 是否意味着将存储在哈希表中的元素数？
您的报价令人困惑。我不确定这意味着什么。

【解决方案2】：

在算法方面，不！密钥的长度在这里无关紧要。此外，密钥本身并不重要，重要的是您预测您将拥有的不同密钥的数量。

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

对于第二个问题，“n”表示要持有的不同键的数量。

【讨论】：

所以哈希表的 size=701 并且它将有 n=2000 个不同的键，以链的形式

【解决方案3】：

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

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

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

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

对于最初的问题 - 哈希表的大小是否取决于键的长度？ - 不，它不应该，至少不是直接的。

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

【讨论】：

所以如果 n=10^5 如果我做 10^5/3 将是哈希表的大小，单个桶中平均有 3 个元素
@sunilsarode 是的，完全正确。每个元素都必须准确地放入一个桶中。当有 10^5 个元素但有 10^5/3 个桶时，平均每个桶三个元素。