使用整数值作为哈希表的键是多么愚蠢？

Posted 2023-02-25

【中文标题】使用整数值作为哈希表的键是多么愚蠢？

【英文标题】：How stupid it is to use an integer value a key for an Hash Table?

【发布时间】：2011-01-23 09:07:24

【问题描述】：

我将需要使用具有不同键的哈希表。一个作为键的字符串，另一个作为整数。

至于整数一，对数字运行哈希函数生成密钥是多么愚蠢？

我的意思是，我将用作哈希表键的数字总是不同的，根本不会有重复。我使用 mod 运算符“截断”哈希表大小以下的值还不够吗？

或者还有更多的东西？

【问题讨论】：

什么平台？ 。网？爪哇？ C++？

也许我错了，但是如果数字是唯一的，为什么不使用数字本身作为键呢？

@Guido：是的，这正是 Java 所做的（不能代表其他任何事情），这也是我询问该平台的原因之一。

对不起，我忘了... C. @Guido，这就是我对问题本身所说的...

【参考方案1】：

这并不愚蠢，这是完全明智的。整数是唯一命名方案中的自然种子。虽然当我说这样的话时，我内心的关系***者有点死了=D

【参考方案2】：

在我看来，这并不愚蠢。如果您倾向于拥有相对较少的值（在这种情况下使用普通数组可能会更好），这可能不是最佳选择。

我会使用模运算符将整数散列到散列大小。

【讨论】：

数组不是这个问题的通用答案，如果这些人有几个数字在 100 左右，然后是一个值，例如 5000，会发生什么 - 这是一个很大的漏洞。

@Hassan，在这种情况下你可以使用sparce数组。

@Hassan，他从未说过或暗示数组将是这个问题的通用答案。一个答案在大多数情况下可能是正确的，但重要的是要认识到“正确”答案取决于具体条件。

谢谢你澄清了stripling——你让我比Romain更清楚——我现在就去考虑你的建议。

【参考方案3】：

如果整数使用排序数组并进行二进制搜索呢？字符串实际上相同，但字符串散列可能更便宜

【讨论】：

二分查找是 O(log n)，哈希表访问是分期 O(1)。是的，我知道 log n > 32...

关键字是“摊销”。您需要考虑您计划使用的哈希表的大小以及您计划存储的项目数和哈希函数。我还是更喜欢二分查找，因为它很简单而且 O(log n) 速度很快。

我会犹豫是否建议使用排序数组，直到我知道他是否希望以及多久添加/删除值，这将是一个 O(n) 函数。

【参考方案4】：

这很好，除非您的整数键很有可能是 62、93、124 ......并且您的哈希表大小恰好是 31。

如果您对此感到担心，请联系What integer hash function are good that accepts an integer hash key?。

【参考方案5】：

与我们领域中的许多设计问题一样，答案是：“视情况而定。”在某些特定情况下，在整数上运行典型的哈希算法会很愚蠢。如果您根据自己的具体情况知道模数会均匀分布预期数据，并且性能对您非常重要，并且如果您需要大量访问此哈希表，那么这将是愚蠢的。除非这些条件，否则有很多很好的理由只使用通用散列算法，该算法在各种情况下都能很好地工作。在绝大多数情况下，不这样做是愚蠢的。在某些情况下，首先使用哈希表是一个愚蠢的选择。

如果您向我们提供了有关您存储的数据类型、存储数据的原因以及性能对您的重要性的更多信息，我们或许可以为您提供比使用哈希表。 Java 和 .NET 等框架具有快速的散列函数，并且可以避免将数字散列到同一个存储桶中。在大多数情况下，我会相信默认的哈希方法。

【讨论】：

很抱歉未能让您满意地回答问题。当人们在没有提供足够背景信息的情况下提出一个非常笼统的问题时，在某些情况下，显而易见的简短答案通常并不正确。我试图指出这一点，同时暗示在大多数情况下使用标准哈希算法并不愚蠢。我只是不够直接，无法表明我实际上是在回答您的问题。希望我的新开头段落有助于澄清我的答案。