Question

我会有一个相当笼统的问题。你有没有必要真正计算（例如在纸上）算法的复杂性，除了在学校作为程序员？如果......你能给我一个例子吗。

谢谢你：）

Answer 1

如果你正在编写一个软件并且你可以想到多种方法来实现它，通常决定因素之一（除了概念复杂性和实现时间之外）将成为算法的复杂性。因此，当你的老板想要为你的决定辩护时，弄清楚每个人的复杂性是必要的。虽然有些人可能认为这是一种过早优化的形式，但我认为共识是选择适合您的问题的设计只是良好的软件工程。

Answer 2

绝对 - 我们刚刚在我们的应用程序中遇到了一个问题，它突然开始出现一些重大的减速。事实证明，我们在一个非常重要的函数中间有一个立方（O（n ^ 3））算法。它被隐藏在抽象层之下。弄清楚发生了什么，需要绘制函数调用图并查看详细信息。

不可否认，一旦我们这样做了，我不得不应用任何数学来注意O（n ^ 3）算法，但这主要是因为3年的大学算法分析给了我一般的感觉一个立方算法看起来像。

无论如何，事实证明N只是增加了一点点，但它正处于从几百毫秒到几秒钟然后再上升到几分钟的尖端 - 所以这个问题没有出现直到最近。

在大多数情况下，您将使用已定义复杂性的预打包算法。 Quicksort是O（n ^ 2）最坏情况和O（n * log（n））平均情况，二进制搜索是O（log（n））等。库通常会指定它们的性能特征是什么，而你只有需要担心他们如何撰写。

Answer 3

在工作中，我们随便讨论不同的算法来解决问题，复杂性发挥其作用。这绝不是我们必须严格证明复杂性的东西，但只是一般性的“我们可以做X，但那是O（N ^ 2）太多了，因为我们可以迭代数百万行。”< / p>

过度优化会导致代码错误，但了解基本算法的复杂性对于确定解决编程问题的最佳方法有很大帮助。

Answer 4

我不知道您是否考虑将比赛编程为学校，但是为了确定您是否可以在时间限制内解决比赛问题（具有指定的问题大小限制），您必须粗略估计操作次数通过考虑所用算法的复杂性。

Answer 5

当然！任何时候，你做了一百多万次，你可能想检查你的算法。

我做的一个例子就是当我生成数百万个必须符合网格图案的图像时。对不起 - 不能更具体的那个。

Answer 6

是。

一般情况下，复杂性对于餐巾纸猜测来说已经足够明显了，这对于开发来说很好，直到我达到需要测量性能的程度。在许多情况下，我担心的部分很好（即，餐巾纸的猜测已经足够好了）而其他东西正在减慢软件速度。几乎在所有情况下，都应该考虑我的基本假设并在以后衡量绩效。

然而，当我正在做非常时间的关键代码时，特别是在图形渲染中，我确实坐下来确定算法的复杂性和与替代方式相关的权衡。

今天我正在与其他代码一起工作，而且速度非常慢。我并不在乎 - 它可能需要10分钟才能完成它所提升的整个过程。但是我必须查看修复bug的代码，这个人在循环内的循环中有循环，大多数循环都以相同的方式搜索同一个列表，每次都有不同的元素。从本质上讲，他改变了一个很好的数组函数，比如func（i）{return records [i];}变成了一个可怕的搜索例程：

func(i)
{
   for each index in records
      if i==index return records[index]
   next
}

现实情况要糟糕得多，但你明白了。

你现在在学校学习这个的原因是你可以看到这些结构并自动分类。您可能不需要实际计算机或将其减少到一个漂亮的复杂数字，但如果您现在不手动执行它并看到很多它，您也将生成这样的代码，您只需要毫无头绪。

- 亚当

Answer 7

我不知道我实际上是在写东西，但是我一直在评估我是如何构建算法的，以确定我是否可以提高它的效率。对于代码，我问自己是否有办法将嵌套循环转换为单个循环或从循环转换为使用分而治之的方法。这相当于从O（N ²）到O（N）和O（N）到O（log ₂ N）。 SQL也是如此 - 我可以删除连接并使用索引执行子查询 - 可能从O（N ²）到O（N）（如果是O（1），则可以它使我能够在两个表上索引查询）。

Answer 8

是和否。

我正在编写一个工具，将一组软件包的RPM依赖关系压缩到一个链中。显而易见的解决方案运行得太慢了，所以我在记忆中挖了一些记忆来自图论类的O(n+m)算法。我做了一些背后的计算，以确保它真的是O(n+m)，然后编写并投入生产：）

算法的复杂性

8 个答案: