有效地计算容器哈希码

时间:2016-10-11 15:24:03

标签: algorithm hash containers time-complexity hashcode

我所知道的用于计算容器哈希码的算法通过递归地组合其中所有元素的哈希来工作。如何将哈希结合起来与我的问题无关。但是因为算法递归,计算会变得非常昂贵。 O(n),其中 n 是可到达的元素总数。

我的问题是,是否有更有效的方法可以做到这一点?例如,如果您有一个包含100k元素的数组,则可以通过组合仅包含的100个元素的哈希值来计算哈希值。这会使计算速度提高1000倍,同时仍然是一个很好的哈希函数,不是吗?

您选择的100个元素可以是100个第一个或每1000个(在上面的示例中)或使用其他确定性公式选取。

所以要回答我的问题,你可以告诉我为什么我的想法无法正常工作告诉我我的想法已经被调查过了。就像我提议的任何编程语言实现“sub O(n)序列散列”一样?

1 个答案:

答案 0 :(得分:1)

通常,设计合适的散列函数需要根据质量来计算计算时间,对于非常大的对象尤其如此。

仅散列大对象的固定大小子集是一种有效的策略(例如,Lua使用此策略来散列大字符串),但是如果散列对象几乎没有差异,那么它很明显会导致问题差异不在散列子集中。这开启了拒绝服务攻击(或意外触发相同问题的输入)的可能性,因此如果您正在散列不受控制的输入通常不是一个好主意。 (如果你使用哈希作为加密练习的一部分,那么省略对象的一部分会使伪造变得微不足道,所以在这种情况下,这是一个非常糟糕的主意。)

假设您正在使用哈希作为数据库索引策略的一部分(即哈希表),请记住最后您需要将查找的值与表中的每个潜在匹配进行比较;那些比较必然是O(n)(除非你相信几乎所有的查找都会失败)。每个误报都需要进行额外的比较,因此质量与计算时间之间的权衡可能会成为一种虚假经济。

但是,最后,没有明确的答案;你必须根据你拥有的确切用例来决定,包括考虑你使用哈希的内容,数据的分布是什么(或可能是什么)等等。