最坏情况复杂度与输入大小成反比的算法？

Question

  

可能重复：
  Are there any O(1/n) algorithms?

任何算法的复杂性随输入大小的增加而减小？

我说的是最糟糕的表现。

一般来说，我们知道数学图表的大小会随输入大小而减小，但我们是否有任何与这些图表匹配的有意义的算法？

Answer 1

这个怎么样？

 Mystery(array[1..n])
 1. x := fn(0)
 2. for i = 1 to floor(1,000,000 / n) do
 3.    x = fn(x)
 4. return x

由于显而易见的原因，所有这些算法都是渐近的渐近时间。

编辑：

实际上，这是渐近O（log n），如果整数除法是对数的，我相信它是。 http://en.wikipedia.org/wiki/Computational_complexity_of_mathematical_operations因此，我的答案是没有任何O（1 / n）算法。 O（1）是最小的复杂性类...除非有一种方法可以使算法能够知道其输入大小的倒数而不计算它！

EDIT2：

我只想到将1,000,000 / n传递给函数作为输入......但这并不是真正的解决方案，因为算法无法判断是否违反了该条件，并且调用者需要计算无论如何。请注意，如果您将算术运算设置为恒定时间，则很多讨论并不是特别相关，因为我非常确定它们位于具有固定大小的内部类型和指令集的计算机上运行定义的寄存器大小。 / p>

Answer 2

像

这样的东西

f(Collection c, query q):
  if q in c:
    do something fast!
  else:
    compute Ackermann function!

f*(Array a, int i):
  if a[i] == i: //Or some other condition that takes constant time to verify,
                //assume i is within bounds
    do something fast!
  else:
    compute Ackermann function!

当然，这的表现依赖于a [i] == i的概率。我没有做过任何彻底的分析，但我想，为了计算这个概率，你需要对数组的性质以及如何调用f *进行某种形式的假设。

考虑起来很有趣，但我无法想象我会遇到过这种情况的案例。

编辑：原始答案是f，但是为了适应哈罗德的评论，将其更改为f *。在f *之后我休息我的情况并且只是潜伏。