列表长度的时间复杂度

时间:2013-12-02 11:08:53

标签: performance lisp common-lisp complexity-theory time-complexity

我认为list-length是一个O( n )复杂操作,因为似乎没有其他方法可以找到它但是遍历所有列表的元素。

;; iterates through list's elements
;; and returns 6, right?
(list-length '(1 2 3 4 5 6)) 

然而,我想确定,因为它对我的作品至关重要。这是对的吗?

3 个答案:

答案 0 :(得分:9)

这是完全正确的,我正在写这句话,因为答案需要至少30个字符。

答案 1 :(得分:3)

HyperSpec对list-length没有时间限制,但确实提供了一个在线性时间内运行的实现。由于可以在线性时间内实现,因此很难想象为什么它不会

值得注意的是,根据cons单元格的实现方式,有可能以list-length实际在O中运行的方式实现list-length (n / k + k)时间。 (当然,这仍然是O(n),但它并不一定要通过所有列表元素。)例如,如果一个实现可以到达{{1}没有访问cddr(例如,可能有某种类型的CDR coding?),那么如果它保持对"当前"的引用。缺点和前一个,它可以在n / 2时间到达列表的末尾,然后再检查一下列表的长度是n / 2还是n / 2 + 1。我只指向这是为了强调cdr(或list-length,就此而言)可能不需要访问"列表的每个元素,如果实现提供了跳过元素的方法。

答案 2 :(得分:0)

显然,你可以为常规列表实现自己的包装器,跟踪已经添加了多少元素,这样就可以找到它的长度为O(1)。