I'm sorry, but I don't understand this. How is that inefficient?
I'm sorry, but I don't understand this. How is that inefficient?
fib 1
1
fib 3
fib 2
fib 1
1
fib 0
1
2
fib 1
1
3
fib 5
fib 4
fib 3
fib 2
fib 1
1
fib 0
1
2
fib 1
1
3
fib 2
fib 1
1
fib 0
1
2
5
fib 3
fib 2
fib 1
1
fib 0
1
2
fib 1
1
3
8
The number of calls grows exponentially. Roughly 1.618^n, to be specific.Yyyyep just tested it:
def fibs(n, tabs=0):
if n < 2:
print "\t"*tabs + "1"
return 1
print "\t"*tabs+"fibs %d"%n
a = fibs(n-1, tabs+1)
b = fibs(n-2, tabs+1)
print "\t"*tabs+str(a+b)
return a+b
Took exactly 71 seconds to write. I probably spent 3 minutes on it by hand getting all the spaces right.http://stackoverflow.com/questions/5749039/automatic-memoizi...
I think the answer is basically that there is no good heuristic about what to store, how much and how long.
In Python you can just put a @memoize decorator before a function you want memoized; would it be possible to have something similar in Haskell?
Note that in Python, you also have the issue that you still need to specify some cleverness about how long something is stored and what is stored. Many example memoize implementations just store everything (e.g.: https://wiki.python.org/moin/PythonDecoratorLibrary#Memoize) but of course that is not a solution in practice.
It should be possible to use UnsafePerformIO to create a generic function memoize function (at least for inputs that implelemt Eq or Ord), but that is almost definantly overkill and asking for space leaks.