Algorithm 为什么我们要测量时间复杂度而不是步骤复杂度？

当我第一次上算法课的时候，我很困惑，当谈到渐近时间复杂度时，实际上测量的是什么，因为它肯定不是计算机运行程序所花费的时间。取而代之的是，我的心理模型是我们在测量渐进步长的复杂性，也就是CPU运行算法所需的渐进步长

---

有什么原因可以解释时间复杂度而不是步骤复杂度，并讨论一个算法需要多少时间，而不是一个CPU执行算法需要多少步骤（渐进地）？

你是对的，我们测量一个算法在图灵机上运行的计算步骤。然而，我们并不计算每一步。相反，我们通常对忽略常数因子的算法的运行时差异感兴趣，就像使用O表示法时一样

而且，我相信这个术语是很直观的。当你谈论一个算法需要多少时间时，每个人都对你的意思有一个基本的理解（我甚至可以向我母亲解释）。但是，如果您谈论一个算法需要多少步骤，您可能会发现自己正在讨论计算模型（什么类型的CPU）

---

时间复杂性这个术语并没有错（事实上，我相信这正是我们所寻找的）。“步骤复杂度”一词可能会产生误导。

事实上，步骤的数量是决定因素，条件是步骤的持续时间不依赖于输入——它所花费的时间不应超过某些选定的恒定时间

这个恒定的时间到底是什么，将取决于运行它的系统。有些CPU的速度比其他CPU快，有些CPU更擅长于一种操作，而不擅长于另一种操作。因此，两个不同的步骤可能代表不同的时间：在一个CPU上，步骤A的执行延迟可能比步骤B短，而在另一个CPU上，则可能相反。甚至可能是，在同一个CPU上，步骤A有时可以比其他时间执行得更快（例如，由于该CPU管道中的某些有利条件）

所有这些都使得仅仅通过测量运行一步的时间来说出有用的话变得不可能。相反，我们认为，对于算法中所识别的所有不同类型的“步骤”，存在一个最大的时间（对于给定的CPU），使得一个步骤的个体执行将永远不会超过该最大时间。 因此，当我们谈论时间复杂性时，我们确实会说一些关于算法所需时间的事情。如果一个算法的时间复杂度为O（n²），这意味着我们可以找到一个值minN和一个常数C（我们可以自由选择），这样，对于每n>=minN，运行该算法所需的总时间T以T

---

简言之，我们在一个步骤和一个时间单位之间建立了一个等价关系，这样一个步骤的执行就可以保证在这个时间单位的范围内。

时间复杂性不度量时间，它度量任意的操作单位。例如，当我们谈论排序或哈希表的时间复杂性时，我们通常计算比较。图灵机执行的步骤通常只在理论上有趣，因为多项式时间算法的计算很困难，而且它们不能很好地模拟现实世界的性能。“位模型复杂性”最像“CPU上的步骤”。嗯，许多常见的时间复杂性不是用“时间”来衡量的。例如，我们计算哈希表操作和排序算法的比较，但在实际CPU上，这些比较可能需要任意长的时间（或者用你的话来说，它可能“比某些选定的常数时间花费更多的时间”）。@PaulHankin，如果CPU上的比较不受任何常数时间的限制，那么我们无法知道算法是否会结束，而任何总时间复杂度的大O表达式都会违反大O的定义。无论比较需要多长时间，排序算法都一定会完成，但你是对的，排序的（walltime）运行时不在任何复杂度类中，除非你添加额外的约束。您能否估计计算机使用固定的快速排序实现对n个字符串进行排序需要多长时间，因为它只是n的一个函数？如果不添加关于字符串大小的额外数据，则不准确。事实上，我明确主张在两个变量（字符串的数量和字符串的最大长度）上定义这种字符串排序算法的时间复杂性，假设字符集的大小是固定的。当我们处于复杂理论更抽象的一端时，我们使用图灵机模型——NP完全等，但在实际应用中，我们计算一些抽象的计算单元（取决于问题）。我认为你是对的，我们应该在做这件事的时候讨论计算模型，但没有人这么做。