懒惰评价的渐近复杂性

时间:2017-07-08 06:23:00

标签: javascript algorithm

在严格的评估中,它更容易推理程序的渐近复杂性,因为因为要评估的子表达式和它们何时被评估在语法上是显而易见的。 Lazy评估的语言不是这种情况。我发现很难推测表达式是O(n) , O(logn) or O(nlogn)

使用Lazy评估解决渐近复杂性的最佳方法是什么?  能帮我解释的人会有很大的帮助

1 个答案:

答案 0 :(得分:0)

通过严格的评估,计算成本=使用成本。

如果您执行xs.map(cos),则需支付cos *长度(xs)的费用。

懒惰评估,使用成本<计算成本。它的具体程度如何,很大程度上取决于计算的形状。

最简单的延迟评估形式之一是布尔表达式的短路。看看(x) => (cheap(x) || expensive(x))

计算成本在很大程度上取决于cheap(x)的实际频率,因此不会调用expensive(x)。同样适用于其他惰性计算,例如使用缓存/ memoization,使用生成器等

在我看来,big-O方法并不适用于这样的问题,除非你能找到问题的大小(大O是关于的)与实际存在的懒惰计算率之间的明确依赖关系。进行。