运行时分析中的概率？答案

【问题标题】：Probabilities in Runtime analysis?运行时分析中的概率？
【发布时间】：2016-03-20 09:59:17
【问题描述】：

这是一个家庭作业问题，我对它的正确方法感到非常困惑。

存在 m 个槽 的哈希表。我们假设 简单统一哈希假设 (SUHA)。

我们执行 n 个插入操作，但所有 n 个元素都映射到 slot 0。（这不太可能，但可能）。

现在问题要求搜索表中可能存在或不存在哈希的随机键“x”。 搜索完成的运行时上限是多少？

这是我的方法：

因为我们假设 SUHA，所以一个键散列到一个槽的概率是 1/m。如果密钥确实散列到插槽 0，则搜索需要 O(n) 时间，否则需要 O(m-1) 时间。按照这个逻辑，解决方案是否是 [1/m]*O(n)+[(m-1)/m]*O(m-1) 简化为 O(n/m + [(m-1) ^2]/米）。

1.可以以这种方式将概率乘以渐近运行时吗？

2。甚至可能在确定运行时间方面发挥作用？

【问题讨论】：

【解决方案1】：

我相信你想错了。不应该考虑概率。由于该问题要求上限，因此将该问题转换为，最坏的情况是什么？

最坏的情况是，如果 x 像之前的每个散列一样散列为 0。现在想象 x 是最后一个散列的元素。您必须遍历可能的位置，直到找到要查找的元素，具体取决于碰撞分辨率。这将使它成为 O(n)，因为它取决于问题中所示的 n 个先前哈希的数量。

最好的情况就是说，如果 x 没有散列到 0。由于计算散列是 O(1)，一旦你散列到一个键，它要么存在，要么不存在，另一个 O(1) 操作总体而言，O(1) 操作。

【讨论】：

是的，我不确定概率是否会成为一个因素。在那种情况下，运行时不会只是 n+(m-1) 吗？（是时候查看链条并查看剩余的插槽了）
没有。为什么您需要查看所有剩余的插槽？地图具有冲突解决方案，它定义了如何存储一个值，如果它散列到一个先前值存在的位置。所以想象一下，如果这使用了单个链表，例如，每个槽存储一个链表，并且 collions 导致值被附加到列表的末尾。搜索的最坏情况是长度为 n 的链表，因此您只需搜索 n 个项目
是的，这是有道理的。如果我修改我的问题并说 n/2 个元素映射到插槽 0 并且 n/2 个元素映射到插槽 1，答案是否仍然保持不变？我真的在想一个概率起作用的情况！
在 O(n) 的情况下仍然会更糟。如果您正在搜索一个值，您将对它进行散列并查看散列计算的槽。您的示例中有两种情况，一种是已经存在 0 个元素，所以 O(1)，另一种是存在 n/2 个元素，这意味着您只需搜索 n/2 个元素，使其成为 O(n)。我可以提供更具体的内容来帮助您了解您的想法吗？
不，现在说得通了。我想我是在强迫自己考虑概率。谢谢！

【解决方案2】：

上限意味着最坏的情况。

当您将概率设为“1/m”时，您正在计算平均情况。

您现在可以尝试这个问题，而无需看下面，因为我将编写解决方案：

最坏的情况是：

在这种情况下，您将不得不遍历该槽的所有元素，导致运行时间为 O(n)。

【讨论】：

当一个密钥被散列时，概率是不是就起作用了。当要搜索已经散列的值（可能在任何地方）时，最坏情况分析会起作用？即哈希完成后进行最坏情况分析？
密钥散列到插槽的概率无关紧要。在具有 m 个槽的映射中，一个键总是散列到相同的值。哈希只是一个常量操作。因此，您不需要到处搜索您要查找的密钥，只需搜索密钥哈希到的插槽，或者如果发生冲突时可能的位置，使最坏情况搜索 O(n)。
@Janmajay：是的，哈希的概率是'1/m'。最坏情况分析意味着假设最坏的情况将发生。最糟糕的是，当哈希索引值变成所有插入值所在的值时。