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

发布于 2024-08-23 07:10:22 字数 166 浏览 7 评论 0原文

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

至于整数一,对数字运行哈希函数来生成密钥是多么愚蠢的事情?

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

或者还有更多的事情吗?

I'll be needing to use Hash Tables with different keys. One as string for the key and another as integer.

As for the integer one, how stupid it is to run a hash function on the number to generate a key?

I mean, the numbers I'll be using as key for the Hash Table will always be different, there will be no duplicates at all. Isn't enough for me to use the mod operator to "truncate" the value below the hash table size?

Or there's something more to it?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

烟─花易冷 2024-08-30 07:10:22

除非您的整数键很可能是 62、93、124...并且您的哈希表大小恰好是 31,否则没问题。

请参阅 什么整数哈希函数可以接受整数哈希键?如果您担心这一点。

It is fine unless there's a high chance that your integer keys are 62, 93, 124, ... and your hash table size happens to be 31.

See What integer hash function are good that accepts an integer hash key? if you worry about this.

一笑百媚生 2024-08-30 07:10:22

正如我们领域中的许多设计问题一样,答案是:“这取决于情况。”在某些特定情况下,对整数运行典型的哈希算法是愚蠢的。如果您根据您的具体情况知道模数会均匀分布预期数据,并且性能对您来说非常重要,并且您需要大量访问此哈希表,那么这将是愚蠢的。除了这些条件之外,还有很多充分的理由来使用通用哈希算法,该算法可以在各种情况下正常工作。在绝大多数情况下,不这样做是愚蠢的。在某些情况下,使用哈希表首先就是一个愚蠢的选择。

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

As with so many design questions in our field, the answer is: "It depends." There are certain, specific cases where it would be stupid to bother running a typical hash algorithm on the integers. If you know based on your specific situation that a modulus would distribute the expected data evenly, and if performance is very important to you, and if you'll need to access this hashtable quite a lot, then it would be stupid. Barring these conditions, there are a number of very good reasons to just use a generic hashing algorithm that will work well across a variety of circumstances. In the vast majority of cases, it would be stupid to do otherwise. In some cases, using a hashtable would be a stupid choice in the first place.

If you gave us more information about the type of data you're storing, why you're storing it, and how important performance is to you, we might be able to point you to a solution that works better than using a hashtable. Frameworks like Java and .NET have hash functions that are fast and avoid hashing numbers to the same bucket. In most cases, I'd trust the default hash method.

黎夕旧梦 2024-08-30 07:10:22

这并不愚蠢,这是完全明智的。整数是唯一命名方案中的自然种子。尽管当我说这样的话时,我内心的关系狂热分子会消失一点=D

It's not stupid, it is perfectly sensible. An integer is a natural seed in a unique naming scheme. Allthough the relational zealot in me dies a little when I say things like this =D

自控 2024-08-30 07:10:22

在我看来这并不愚蠢。如果您的值相对较少(在这种情况下使用普通数组可能更好),那么它可能不是最佳选择。

我会使用模运算符将整数哈希到哈希大小。

In my opinion it's not stupid. It may not be the best option if you tend to have relatively few values (in which case using a plain array could be better).

I'd use the modulo operator to hash integers to the hash size.

浮生面具三千个 2024-08-30 07:10:22

如果整数使用排序数组并进行二分搜索怎么办?实际上对于字符串来说是一样的,但是对于字符串散列可能更便宜

what about in case of integer to use sorted array and do binary search? actually same for string, but for string hashing may be cheaper

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文