O(1/n)并不小于O(1)这基本上意味着你拥有的数据越多，算法运行得越快。假设你有一个数组，如果它小于10100个元素就填充它，如果多于10100个元素就什么都不做。这个当然不是O(1/n)，而是O(-n):)太糟糕了，O大符号不允许负数。

这里有另一种方法来证明它:为了拥有一个函数，你必须调用这个函数，并且你必须返回一个答案。这需要固定的时间。即使余下的处理过程对较大的输入花费更少的时间，打印出答案(我们可以假设是单个位)至少需要常数时间。

我经常用O(1/n)来描述随着输入变大而变小的概率——例如，在log2(n)次投掷中，一枚均匀硬币背面朝上的概率是O(1/n)。

这个问题并不像有些人认为的那样愚蠢。至少在理论上，当我们采用大O符号的数学定义时，像O(1/n)这样的东西是完全合理的:

现在你可以很容易地用g(x)代替1/x……很明显，上面的定义对于某个f仍然成立。

为了估计渐近运行时增长的目的，这是不太可行的……一个有意义的算法不能随着输入的增长而变得更快。当然，你可以构造一个任意的算法来实现这一点，例如下面这个:

def get_faster(list):
    how_long = (1 / len(list)) * 100000
    sleep(how_long)

显然，随着输入大小的增长，这个函数花费的时间更少，至少直到硬件强制的某个限制(数字的精度，睡眠可以等待的最小时间，处理参数的时间等):这个限制将是一个常数下界，因此实际上上面的函数仍然有运行时O(1)。

但实际上，在现实世界中，当输入大小增加时，运行时可能会减少(至少部分减少)。但是请注意，这些算法不会在O(1)以下表现出运行时行为。不过，它们还是很有趣的。以Horspool的非常简单的文本搜索算法为例。在这里，期望运行时将随着搜索模式长度的增加而减少(但是增加草堆长度将再次增加运行时)。

没有比O(1)小的数 大o符号表示算法的最大复杂度

如果一个算法的运行时间是n³+ n²+ n + 5那么它就是O(n³) 低次在这里根本不重要，因为n ->正无穷，n^2与n^3相比是无关的

同样地，当n -> Inf时，O(1/n)与O(1)相比是不相关的，因此3 + O(1/n)将与O(1)相同，从而使O(1)的计算复杂度最小

如果不管输入数据如何，答案都是一样的，那么你就有一个O(0)算法。

或者换句话说——在提交输入数据之前，答案就已经知道了 -这个功能可以优化-所以O(0)