假设我们可以证明使用大小为n的输入调用的算法及时运行O(f(n))。
我想证明这个运行时限很紧。两个问题：
f(n)是不够的？答案 0 :(得分：5)
提供特殊输入并显示正在运行是不够的 时间至少是f（n）？
是的，假设您正在谈论最坏情况复杂性 。
如果你在谈论最坏情况的复杂性 - 并且你已经证明它在O(f(n))中运行，如果你找到的输入比某个常数C*f(n))更“差”C - 您有效地证明了算法（在最差情况下的性能）在Ω(f(n))，并且从O(f(n)) [intersection] Ω(f(n)) = Theta(f(n))开始，这意味着您的算法在最坏情况分析中在Theta(f(n))中运行。
注意它实际上应该是示例的“系列”，因为如果我声明“是的，但这只适用于小n值，而不适用于{{ 1}}（对于某些n>N），您可以告诉我此系列示例还涵盖N的情况，并且仍然有效。
对称地，如果您证明算法具有n>N的最佳案例性能，并且您发现某些输入对某些常量Ω(f(n))运行“比”C*f(n))“更好”（更快），那么在最佳案例分析下，有效地证明了算法是C。
这个技巧不适用于平均案例分析 - 你应该计算运行时的预期，而单个例子没有用。
我读过，证明紧张的一种可能性是“减少 排序到它“。我不知道那是什么意思
这样做是为了证明一个更强大的主张，即没有算法（根本没有）可以在所需的时间解决某些问题。
它的常见用法是假设有一些黑盒算法Theta(f(n))在某个A时间内运行，然后使用o(g(n))构建一个运行于其中的排序算法{{1次。但是，由于排序是A问题，我们之间存在矛盾，我们可以得出结论o(nlogn)的假设是错误的，并且无法在所需的时间内运行。
这有助于我们证明一个更强大的主张：不仅OUR算法具有此下限，而且解决特定问题的所有算法都具有此下限。
答案 1 :(得分：1)
ad 1。：是的，但您必须能够为任何n找到大小为n的输入。以9个步骤处理的大小为3的示例并没有真正证明什么。
ad 2。：如果你可以修改一系列元素，以便你的算法有效地对它进行排序（你在输出一些处理后得到一个排序的序列），你就减少了对它的排序。并且因为排序（通过比较）不能比O（n log（n））快，所以这可以用来证明你的算法不能比O（n log（n））更快。
当然，输入和输出处理函数不能慢于或等于O（n log（n）），这个参数才有效，否则你可以对数组进行排序并证明一个O（1）算法只返回输入数组实际上至少是O（n log（n））：）。