为什么在最坏的情况下unorder_set重哈希复杂度可能是O(n^2)

Why unorded_set rehash complexity could be O(n^2) in worst case?

本文关键字：复杂度 哈希 最坏 情况下 unorder set 为什么      更新时间：2023-10-16

我不明白为什么它不是线性的。

对于multiset的类似问题有一个很好的答案:为什么hastable's的重哈希复杂度在最坏情况下可能是二次的

但是set呢?每个键只能有一个元素。

更新:

一个桶中有多个键也不是问题。我们可以在线性时间内遍历它们

我认为下面提到的正确答案是O(n^2)重新哈希复杂度包含在标准中，以允许开放寻址(可能是其他一些)实现。

基本上，可以构建具有O(n)最坏情况重散列时间的散列集。甚至可以用这个属性构建一个multiset，它仍然授予相同的保证，即具有相同键的元素在bucket中彼此后面，因此您所声明的链接是错误的。(好吧，不是完全错误，它承认可能存在O(n)实现)

它是这样工作的:

for each bucket b of old table
    for each element e in bucket b
        b' = new bucket of e
        prepend e before the first entry in b' // <---- this is the key optimization

该算法适用于集合和多集合，并且非常简单。而不是追加元素到新的桶(这将是O(number of elements in the bucket))，我们追加到桶是O(1)(简单地改变两个指针)。

当然，这将反转桶中的元素。但这是可以的，因为关键的multimap假设相等的元素在彼此后面仍然成立。

但要注意开放寻址

我的解决方案只适用于哈希链。它不适用于开放寻址。因此，由于规范肯定希望允许两种实现方法，因此必须声明O(n²)可能是最坏的情况，即使存在具有更好的渐近运行时的实现。

相关文章：