我目前正在学习“第3版算法介绍”中的哈希表。从统计角度尝试理解开放式寻址时，要相当困惑。线性探测和二次探测只能生成m个可能的探测序列，假设m是哈希表长度。然而，如在开放寻址中所定义的，可能的密钥值数量大于散列值的数量，即负载因子n / m <1。 1.实际上，如果预定义了散列函数，则只存在n个可能的探测序列，其小于m。同样的事情适用于双重散列。如果书中说，从一组通用哈希函数中随机选择一个哈希函数，那么，我可以理解。如果不在开放式寻址分析中引入随机性，那么基于通用散列的其性能分析就会变得模糊不清。我从来没有在实践中使用哈希表，也许我对细节进行了过多的研究。但我对哈希表的实际用法也有这样的疑问：
问：实际上，如果负载系数小于1，我们为什么还要打开寻址？为什么不将每个键投影到一个整数并将它们排列在一个数组中？答案 0 :(得分：0)
问：实际上，如果负载系数小于1，我们为什么还要打开寻址？为什么不将每个键投影到一个整数并将它们排列在一个数组中？
因为在很多情况下使用哈希表时，没有好的O（1）方式将每个键投射到[distinct，not-absurdly-scarse]整数＆＃34;数组索引。
一个简单的思想实验说明了这一点：假设您希望用户键入四个三个大写字母的键，并且您希望将它们存储在一个维度为10的数组中。您有26个 4 可能的输入，所以无论你的逻辑是什么，平均26 4 / 10将＆＃34;投射到一个整数＆＃34; 表示相同的阵列位置。当您意识到＆＃34;项目[离子]＆＃34; 无法避免潜在的＆＃34;碰撞＆＃34; ，并且该投影是与＆＃34;哈希＆＃34; 的逻辑完全相同的操作以及对＆＃34;桶＆＃34; 的修改，则需要一些冲突处理逻辑，你提议的＆＃34;替代品＆＃34;变形为哈希表....
线性探测和二次探测只能生成m个可能的探测序列，假设m是哈希表长度。然而，如在开放寻址中所定义的，可能的密钥值数量大于散列值的数量，即负载因子n / m <1。 1。
他们的陈述非常混乱。 ＆＃34;哈希值的数量＆＃34;不是任意限制的 - 您可以使用32位哈希生成~40亿个哈希值，512位哈希值或任何其他您想要的大小。鉴于您的陈述结构是＆＃34; a＆gt; b，即负载系数n / m <1。 1＆＃34;和＆＃34; n / m＆lt; 1＆＃34;可以改写为＆＃34; n＆lt;米＆＃34;或者＆＃34; m＆gt; n＆＃34;，你暗示＆＃34; a＆＃34;和＆＃34; m＆＃34;和＃34; b＆＃34;是一样的。和＆＃34; n＆＃34;：
您指的是m - ＆＃34;加载因子n / m＆＃34; 需要哈希表中的桶数 - as ＆＃34;可能的键值编号＆＃34; ：它不是，这甚至意味着什么？
您指的是n - ＆＃34;加载因子n / m＆＃34; 需要是存储在哈希表中的键数 - 作为＆＃34;哈希值的数量＆＃34; ：它不是，除了那么多（不一定是不同的）哈希的琐碎意义密钥被散列时生成的值
实际上，如果预定义散列函数，则只存在n个可能的探测序列，小于m。
同样，这是一个定义很差的陈述。 n密钥的散列可以识别最多n个不同的存储区，冲突处理将从这些存储区中启动，但n个m可以在{{1}}存储区内的任何位置开始，鉴于哈希函数的作用是喷洒它们。那么，是什么？
同样的事情适用于双重散列。如果书中所说，从一组通用哈希函数中随机选择一个哈希函数，那么，我可以理解。
明白什么？
在开放式寻址分析中不引入随机性，基于通用散列的性能分析模糊不清。
当然可以。 ＆＃34;可重复的随机性＆＃34;散列是一个非常方便和有形的基准，可以比较特定的实现。
我从未在练习中使用哈希表，也许我对细节过分了解。但我在哈希表的实际用法中也有这样的疑问：