为什么这个简单的 O(n) Haskell 算法表现得更像 O(2^n)？ [复制]

Question

Haskell 缓存纯函数调用的结果，这是区分纯行为和不纯行为的众多原因之一。然而，这个函数应该在 O(n) 中运行，其中 n 是下面的50，运行速度非常慢：

lucas 1 = 1
lucas 2 = 3
lucas n = lucas (n-1) + lucas (n-2)
map (lucas) [1..50]

前 30 项左右一起计算不到一秒，然后 31 需要半秒左右，32 需要一整秒，33 需要几秒，34 需要 6 秒，35 需要 11 秒，36 需要 17秒...

为什么这个功能这么慢？如果 GHC 交互式运行时正在缓存结果，那么对 lucas 的每次调用应该只涉及对前两个缓存项的求和。一次加法运算可找到第 3 项，一次加法运算可找到第 4 项，一次加法运算可找到第 5 项，因此在考虑缓存的情况下，总共只有 48 次加法即可达到第 50 项。该函数不应该花费任何时间来找到至少前几千个术语，为什么性能如此糟糕？

我已经等待lucas 500 计算半个多小时了。

Answer 1

您的版本非常慢的原因是lucas (n-1) 和lucas (n-2) 部分没有memoization - 所以这两个值将一遍又一遍地重新计算（递归） - 这是慢得令人痛苦。

解决方案是将计算值保存在某处：

使用列表惰性

这是一个简单的版本，它的作用与您的 code-sn-p 相同，但应该更快 - 它会将已经计算的部分保留在列表本身中：

lucasNumbers :: [Integer]
lucasNumbers = 1:3:zipWith (+) lucasNumbers (tail lucasNumbers)

first50 :: [Integer]
first50 = take 50 lucasNumbers

这样更快的原因是现在列表的惰性可以帮助你记忆不同的部分

如果您寻找Fibonacci sequences in Haskell，您可以了解很多相关信息（它真的和您的一样；））

使用unfoldr

另一种（可能不那么magic看起来）方法是使用Data.List.unfoldr - 这里已经计算的部分（或重要的部分 - 最后一个和倒数第二个元素）将是在 state 中，您为 unfold 操作传递：

lucasNumbers :: [Integer]
lucasNumbers = unfoldr (\ (n,n') -> Just (n, (n',n+n'))) (1,3)

---

您的评论/问题：

假设您在谈论x(n) = x(n-1)^2-2，那么您可以这样做：

lucasLehmer :: [Integer]
lucasLehmer = 4 : map (\ x -> x^2-2) lucasLehmer

会产生这样的结果：

λ> take 5 lucasLehmer
[4,14,194,37634,1416317954]

也许你应该自己试试unfoldr 版本