If anyone had ever set eyes on Cracking the Coding Interviews (or any other books on algorithms), you might at least know what memoization is and what it's good for. Consider this a more comprehensive, layman, JavaScript version of the excerpt.
There's no problem that can explain (bad) recursion simpler than finding the n fibonacci number, so here goes:
function fib(n) {
if (n == 0 || n == 1) return n;
return fib(n - 1) + fib(n - 2);
}
Oh no, the syntax highlighting isn't working for you? No worries, that was just me. IMO, highlighting is quite distracting for reading code especially this small. It is helpful in writing, but you want to focus on the logical steps and make sure you get them while reading.
It's pretty straightforward. A recursive function with one or more base cases (in this case, when n == 0 and n == 1) and the recursive one. If you have no clue what how recursion works at all, I recommend a soft consultation of this post: Recursion Made Simple. (And don't forget to clap and follow me. It takes time and effort to write!)
The problem with the said fib function is it runs at exponential time O(2^n). That's like (almost) the worst runtime you could get into. How bad exactly? If you called fib(50) to compute the 50th fibonacci number and it took a minute to return the result, then calling fib(100) will take you roughly 1,125,899,906,000,000 minutes (rounded down to the millionth), which is just around 2 billion years (Fun fact: By then our earth and half of the solar system should have been eaten by the growing sun long ago).
To be fair, this problem is an intentional bad candidate for recursion. This recursive part:
fib(n - 1) + fib(n - 2);
means that for every Nth node of the function call, two more branch out. To make this worse, for each Nth call, there are works repeated. Below is a painstakingly created ASCII tree diagram of what really happens:
fib(5)
/ \
fib(4) fib(3)
/ \ / \
fib(3) fib(2) fib(2) fib(1)
/ \ / \ / \
/ \ fib(1) fib(0) fib(1) fib(0)
fib(2) fib(1)
/ \
fib(1) fib(0)
As you can see, the work done from fib(3) down could be done once instead of repeated the way it is. When N = 5, you could see that fib(N - 2) is being computed twice, fib(N - 3) three times. If this goes on long enough, says N is a high number like 100, you can be sure that
For every
fib(N),fib(N - (N - p))will be repeatedptimes wherep ∈ {x | 2 < x < N}(pis element ofrange (2..N-1)). Talking about baggages!
Memoization = Memorizing the past
As melodramatic as it may sound, that sums up the definition of this technique. Imagine your code is equipped with AI capability to not repeat the amount of work we mentioned. Still, the AI needs to have a way of memorizing what has been done. In this case, the fictitious AI isn't going to be of much help. The smartest thing it could do is to realize that the fib operation is a suicidal mission and switch to memoization mode from the get.
And what's the best way our brain remember and recall a memory quickly? By associating it with something else. That is exactly how associate arrays (hash map, hash table, dictionary) and arrays work!
In our fibonacci case, we could use either data structure, but array is simpler since the keys are already integers.
The concept is to have the fib function "carries along" an array filled with past memories so at any moment in its mesmerizing recursive life, it can recall that a work it's about to do had actually been done already and should just be lazy about it. Here is how it's done:
function fib(n, brain = []) {
if (n == 0 || n == 1) return n;
// If brain has no memory of the work for fib(n)
if (brain[n] == 0) {
// compute and then memorize it
brain[n] = fib(n - 1, brain) + fib(n - 2, brain);
}
// just returns what's already memorized
return brain[n];
}
Now whenever fib gets called, it carries along a brain with memories of the past work, just so that it could avoid doing work more than once. This will of course come with having to sacrifice a linear amount of space for brain array, but now you gets to finish computing fib(10000) in fractions of a millisecond instead of waiting for the universe to die out twice over.
p.s. I'll leave it to you to figure out the new runtime of our "mindful" fib.
ciaos
Top comments (11)
One fix needed:
needs to be
(also uses
===as best practice)Otherwise an error happens:
Oh, shoot! Thank you. I thought that could implicitly return.
About the
===it's very funny because now we don't have to use==again, although it is totally fine for integers like this case.===: Yeah, I just picked up this habit, as it is usually the safer option, especially when processing external/user input.return: JS is one of the langs without implicit returns. Nevertheless in the middle of a function we need to be explicit anyway, since more code follows afterwards. If implicit returns were supported you could use an else block to avoid a keyword, but also not worth the effort.Yeah I was hoping es6 is closer to functional than this. The only way to get an implicit return from the last expression is a lambda function without brackets (containing a single expression).
And for the brain version:
Or
undefinedwill be the only result.The parallel with AI is really weird. Memoization is just a form of cache for pure functions, it's way simpler than anything AI related
You're probably right. However, I was trying to kind of wrap this concept of memory / caching with the "brain". So I was trying to suggest that even with a super smart AI doing this it would still use this technique to memorize.
I understand recursion well enough, I just open the blog and clap for it
Thank you!
Nice overview Joe.
Thanks Ben!