4 ms·
Hmm, I'm not sure that's quite right. The time taken by f(g(x)) under lazy evaluation is known to be no more than the time taken under strict evaluation. It's
by tome 7y ago
Hmm, I'm not sure that's quite right. The time taken by f(g(x)) under lazy evaluation is known to be no more than the time taken under strict evaluation. It's the space usage that can be hard to predict.
- reitzensteinm 7y agoIt's not more operations, but that extra space usage can mean the difference between creating and freeing objects with bump allocation in Eden that fits in cache, and walking over the heap doing a full GC so you don't run out of memory. There's a very real difference between what a simplified model of time complexity says should happen, and what actually happens when the layer of abstraction underlying the ivory tower start to spring a leak.
- lmm 7y ago> The time taken by f(g(x)) under lazy evaluation is known to be no more than the time taken under strict evaluation. True but irrelevant (particularly given that idiomatic Haskell involves a lot of constructions that would take infinite time under strict evaluation). If x < a, y < b, z < c and a + b = c, that doesn't give you any useful relationship between x, y and z.
- tome 7y agoA fair point. An example would be something like take 10 (map (+1) [1..])
- TheCoelacanth 7y agoI don't think that's true in practice because excessive memory usage can lead to slower execution.