是否无法计算维基百科所说的确切最坏情况？

Question

根据wikipedia：“通常无法确定确切的最坏情况。相反，情景被认为至少与最坏情况一样糟糕”。我不明白那一部分。搜索列表中的数字是否是最后一个索引时的最坏情况？这不是最坏的情况吗？

Answer 1

我认为你误读了这个条目。 http://en.wikipedia.org/wiki/Best,_worst_and_average_case

他们说最坏的情况可能是你可以识别的东西，但确切的输入不是。例如，如果使用存储桶实现哈希表/字典，则很容易说最坏的情况是所有100个样本条目都散列到同一个存储桶，但不太容易识别实际散列到同一存储桶的100个输入。对于某些算法，可能几乎不可能得出确切的最坏情况输入数据。

  

最坏情况分析也存在类似问题：通常不可能   确定确切的最坏情况。相反，一个场景是   被认为至少与最坏的情况一样糟糕。对于   例如，在分析算法时，可能会找到   通过算法的最长路径（通过考虑   即使不可能，例如，最大循环数   确定生成此路径的确切输入（实际上，这样   输入可能不存在）。这给出了一个安全的分析（最坏的情况是   从来没有被低估过），但有一个是悲观的，因为有可能   没有需要这条路径的输入。

Answer 2

是的，这是您提到的场景的最坏情况，但您提到的场景是一个简单的场景。

想象一下，在树上进行复杂的操作，包括将节点一直旋转到根节点。情况可能是最坏情况是树的当前状态的复杂函数。但是，更容易想象，你需要做O（log（N））或O（N）旋转，这取决于你是否可以证明哪一个比最坏的情况更糟（当然O（N）是一个在这个更复杂的情况下，最坏的情况就会受到限制。）

Answer 3

要计算最坏情况执行时间（WCET），您将根据输入大小考虑每个循环，并假设它不会提前终止。但是，如果您的算法有点复杂，则可能无法计算导致WCET的输入。例如，如果您的算法使用散列表（名称），您可以假设所有键都散列到同一个单元格，但您无法确定哪种输入会导致这种情况。虽然甚至可能看到输入语义永远不会导致这样的哈希表，但您仍然会基于所有键具有相同哈希的假设来计算WCET。