因此，当有人要求您提供O（n）或O（nlogn）算法来计算某些内容时，您如何知道要回答什么？似乎能够回答这类问题的唯一方法是事先了解各种算法的时间复杂性，而不是在现场思考问题。我假设这是正确的吗？
答案 0 :(得分：11)
简单的案例是：
沿列表迭代 - O（n）
单个二进制或树操作 - O（log n）（这意味着在树中插入n个元素是n log n）
哈希表操作 - O（1）
NP完全问题（这里需要一些经验来形成直觉） - 一般指数时间（在实践中可以应用有效的启发式算法）
对于具有E边和V顶点的图，复杂度为F（E，V），这取决于算法的性质和图的密度。 E + V表示良好的DFS / BFS。
几乎每个算法都可以划分为上面（或类似）小块的集合。当递归组合块时，如A-includes-B，复杂性倍增，当块相互跟随时，如A-then-B，复杂度为max（复杂度A，复杂度B）
答案 1 :(得分：2)
你是对的，你应该知道不同算法的时间复杂性来了解这一点。 您应该知道排序的时间复杂性，查找字典中的项目，哈希表，联合查找，流程图，DFS，BFS，最小生成树等等。这些都是基础知识。
Introduction to Algorithms应该让你受到很好的保护。
答案 2 :(得分：1)
但是，说真的，你需要知道常见问题的算法的复杂性，例如迭代，搜索，排序，哈希表查找等。例如，知道一个简单的排序算法是很有帮助的。冒泡排序为O（n ^ 2），并且快速排序在平均情况下为O（n log n）。同样重要的是能够快速分析算法以确定其复杂性，并了解如何更改它以使其更快。
答案 3 :(得分：1)
这离事实并不太远。有几种系统的方法，但它们很难，即便如此，它们往往会在某些时候获得“捷径”。
Big-O给出了上限。如果有人问您任何算法并且您不知道，您可以说O（n ^ n）并且可能是正确的（尽管那里的算法甚至更慢）。当然，这不是紧界限。
当您发现一个证明特定上限的模式时，“快捷方式”基本上就是灵感点。
99％的时候，大多数人只是利用自己的直觉找到一种好看的算法，然后做足以证明这一点。例如，不是查看实际的执行流程，而是通常说“每个项目最多处理x次，每次处理恒定时间”（对于O（n）算法）。您可能错过了例如至多log n项目都经过处理，但是如果你真的知道算法正在做什么，这是不太可能的。当然，这可能无法帮助您完成算法课程。
对于系统方法 - 嗯，有“MIT 6.046J / 18.410J算法简介”课程视频可以在YouTube上观看。讲师是备受尊敬的algorithms textbook的作者之一。
答案 4 :(得分：0)
这可能比你正在寻找的更具学术性，但是值得知道的是，对于某些问题，可以证明任何解决它的算法都不会比某些下限更好。例如，a comparison sort won't do better than O(n log n)。另一个例子是河内之塔，由于问题的构建方式，任何解决方案都必须是指数级的。
Some discussion of lower bounds on mathoverflow ...将其与完整性联系起来，我不知道它的实际阅读情况如何：D
无论如何，有时候要问的问题是，可以在给定的时间内完成吗？
除此之外，像其他人一样说：掌握哪些算法用于解决哪些问题的工作知识。波巴有很好的例子。 （请注意，散列表操作并不总是保证为O（1），但预计是。）
答案 5 :(得分：0)
我这样做的方式更务实。
我所知道的另一种方式是，如果你真的找到问题的理论复杂性并进行渐近分析。