寻求最佳算法（渐近）并忽略其他细节

Question

在某些情况下，对问题采用蛮力方法的复杂性在性能方面不够好。

让我们举个例子，例如θ(n^2)。

使用递归方法可以将其改进为 Theta(nlogn)。

显然，渐近地人们会选择使用递归方法，因为对于越来越大的输入 N，增长的顺序会更低，即更好的性能。

我的问题如下：

如果随着 N 越来越大，递归（即分而治之的方法）的性能会越来越好，那么当我们对 N 的 huge 输入进行递归时，忽略这一点不是不切实际吗？出栈？
由于大量输入，我们实际上从未得到结果。

那么，如果我们忽略这些细节，我们如何确保为特定问题选择最佳算法呢？

Answer 1

可以在不使用硬件堆栈的情况下实现递归算法。如果堆栈溢出的可能性是一个严重的问题，您可以实现自己的堆栈或简单地限制递归的深度。

但是，如果算法递归地划分一组数据（大小为n），则递归数将与log n 成正比。这意味着要耗尽大小为s 的堆栈，您需要大小为2^s 的数据，随着s 的增长非常快。人们往往不会意识到指数函数增长的速度有多快。我的观点是，使用这种类型的算法（在每个递归步骤中拆分一组数据），输入数据不太可能大到需要如此多的递归以耗尽堆栈。

编辑：但是我不是专业的程序员，所以我缺乏实践经验。

Answer 2

这是我第一次在快速排序中看到的一个有用的技巧：

f(x)
{
  for (;;)
  {
    if (x is trivial)
    {
      return;
    }
    x1 = one half of problem x
    x2 = other half of problem x
    if (x1 is the little half)
    {
      x = x2;
      f(x1);
    }
    else
    {
      x = x1;
      f(x2);
    }
  }
}

关键在于，每个递归调用都针对问题的一小部分——通常小于原始问题的一半——而问题的较大一半是通过迭代完成的。如果问题的大小为 2^n，则堆栈的大小只需为 n，即使 - 由于拆分非常不均匀 - 您最终花费的时间接近 n^2 而不是 n log n。

就使用 n log n 时间但会加载堆栈的算法的“实际成本”而言，请注意，在 n log n 时间内运行的算法没有时间使用超过 n log n 的内存，所以堆栈的负载和负载实际上不可能是大量的内存，尽管它可能足以让例如Java 解释器会在您的递归失控的印象中使您的程序崩溃。