为什么遍历列表是线性时间？

如何解决为什么遍历列表是线性时间？

每个人都知道长度为n的列表可以在O（n）时间中遍历。这是因为假定从列表的一个元素到下一个元素的每个步骤都在O（1）时间中完成。如果我知道我需要存储的最长列表的长度最大为4，那么我将安排（如果可以的话）将每个元素存储在具有2位地址00、01、10之一的寄存器中，或11.然后，读取正确地址并到达该地址的任务只需要知道几位。 但是，我一直认为，如果列表的长度约为2 ^ 100，则指针的使用会变慢。看来，要区分列表中两个不同元素的寄存器，处理器首先必须先消化100位地址信息，然后才能知道接下来要处理哪个寄存器。这将使每个步骤的时间需求更像Theta（log n），而完整遍历的时间需求为O（nlog（n））。

解决方法

您完全正确。如果有人说遍历一个O（n）列表，则基于这样的假设：您可以在恒定时间内从一个元素到另一个元素。如果更改这些假设，则可能会获得不同的时间复杂度。

当人们陈述算法的时间复杂度并用它来讨论实际计算机上的执行时，通常掩盖了以下事实：

在实际的物理计算机上，不同可能输入的数量始终是有限的，因此计算机实际上是有限状态机（而不是图灵机），并且每种算法的复杂度严格为O（1）说话（可能有相当大的常数！）。但是我们外推这个有限状态机来推断它的行为，就好像它不是有限的一样。

在您的示例中，列表遍历算法的可能输入的有限数量（实际上）受CPU字长（例如64位）的限制，并且您不能拥有长度为2 ^ 100的列表（通常基于指针的算法）。因此严格来说，在64位CPU上遍历列表的复杂度为O（1），但在可能的输入范围内表现为 O（n）。对于超出该范围的输入，外推分解。在真正的物理计算机上运行的 all 算法就是这种情况。

,

您混淆了不同的用语。 n是指列表中元素的数量。 从一个元素到另一个元素的传播时间通常通常被认为是O（1）。 只要地址分辨率受常数限制，非平凡的地址分辨率示例就不会对整体复杂性产生影响。因此，即使列表中有2 ¹⁰⁰ 个元素，并且CPU必须执行一些其他操作来检索下一个元素，但仍然需要O（1）才能到达它，更大的常数。仅当检索以某种方式取决于列表中元素的总数时，复杂性才会受到影响，这将是非常尴尬的情况。可能，但是很尴尬。例如，考虑下一个元素地址不是由下一个指针给出的，而是在某个内存位置进行加密的，并且要检索它，您需要k次应用解密算法，当{{1 }}是列表的长度，直到当前元素为止。在此示例中，单跳的价格确实取决于列表的长度，总复杂度也会增加。

注意：这里的假设是物理计算机没有内存限制（否则，根本谈不上复杂性是没有意义的，因为所有算法都需要O（1）时间）