开放式寻址分析

Question

我目前正在从“算法简介3”中学习哈希表。 尝试从统计角度理解开放式寻址时会感到很困惑。 假设m为哈希表长度，则线性探测和二次探测只能生成m个可能的探测序列。 但是，如在开放式寻址中定义的那样，可能的键值数量大于哈希值的数量，即负载因子n / m <1。实际上，如果预定义了哈希函数，则仅存在n个可能的探测序列，即小于m。 同样的情况也适用于双重哈希。 如果这本书说的是，从一组通用哈希函数中随机选择一个哈希函数，那么我可以理解。 在开放寻址分析中没有引入随机性的情况下，基于通用哈希的性能分析就变得模糊了。 我从未在实践中使用过哈希表，也许我过多地研究了细节。 但是我对哈希表的实际用法也有这样的疑问：

问：实际上，如果负载系数小于1，为什么还要打扰开放式寻址？ 为什么不将每个键投影为整数并将它们排列在数组中？

Answer 1

问：实际上，如果负载系数小于1，为什么还要打扰开放式寻址？ 为什么不将每个键投影为整数并将它们排列在数组中？

因为在许多情况下使用哈希表，所以没有很好的O（1）方法“将每个键投影到[清晰，不稀疏的]整数”数组索引。

一个简单的思想实验说明了这一点：假设您希望用户键入四个三个大写字母的键，并且希望将它们存储在维度为10的数组中的某个位置。您有26个^4个可能的输入，因此无论您的逻辑是什么，它们的平均26 ^十分之四将“项目...的整数”表示在相同的阵列位置。 当您意识到“ project [ion]”无法避免潜在的“碰撞” ，并且投影在逻辑上与“散列”并修改为“ bucket”的操作相同时 ，则需要一些冲突处理逻辑，您的建议的“替代”变形返回到哈希表中。

假设m为哈希表长度，则线性探测和二次探测只能生成m个可能的探测序列。 但是，根据开放式寻址中的定义，可能的键值数量大于哈希值的数量，即负载因子n / m <1。

他们的陈述很混乱。 “散列值的数量”没有任意限制-您可以使用32位散列来生成约40亿个散列值，512位散列或任何其他您喜欢的大小。 给定语句的结构为“ a> b，即负载系数n / m <1”，并且“ n / m <1”可以重写为“ n <m”或“ m> n”，则表示“ a “”和“ m”与“ b”和“ n”的含义相同：

• 您指的是m “负载因子n / m”要求是哈希表中存储区的数量-作为“可能的键值编号” ： 不是 ，那甚至意味着什么？

• 您指的是n “负载因子n / m”要求是存储在哈希表中的键的数量-表示为“哈希值的数量” ： 不是 ，除了这么多的琐碎意义（不一定是散列键时生成的不同值）

实际上，如果预定义了哈希函数，则仅存在n个可能的探测序列，小于m。

同样，这是一个定义很不明确的语句。 n键的散列最多可以标识将从中进行冲突处理的n不同的存储桶，但是鉴于散列函数的工作是将它们散布在周围，因此这n可以在m存储桶中的几乎任何位置开始。 而且，那又如何呢？

同样的情况也适用于双重哈希。 如果这本书说的是，从一组通用哈希函数中随机选择一个哈希函数，那么我可以理解。

明白什么？

在开放寻址分析中没有引入随机性的情况下，基于通用哈希的性能分析就变得模糊了。

当然。 哈希的“可重复的随机性”是一个非常方便且切实的基准，可以将其与特定的实现进行比较。

我从未在实践中使用过哈希表，也许我过多地研究了细节。 但是我对哈希表的实际用法也有这样的疑问：