If you put your list inside of your function, then it is not memoization, because the list gets forgotten between calls and has to be rebuilt every time. When you have the list outside, it survives and can be reused between calls.

Same. My solution is not recursive; but when I put the initialization vector outside of the function it works, when it is inside of the function it does not. I am confused.

Actually cool kata. Required me to think a lot and to debug my code a few times.

Why was the kata still on Node 8?

it need not be a consideration. Node 8 is only supported for legacy reasons. if you use padStart(), the runner will take notice that the kata no longer compiles with Node 8 and disable that version.

(besides, Node 8 does support padStart())

This kata allows Node v8.0 which doesn't support padStart

padStart is available natively. Why reinvent the wheel?

I've created a fork with a fix

(The user attempted in JavaScript.)

In the assumptions:

• both numbers in the pair will be of the same length
• If a number is shorter, it will be zero-padded.

The actual input:

Input:
537302 92264

Something is wrong I guess

Enabled in this fork

Is anyone else failing the final speed test? Mine keeps timing out and I implemented memoization correctly. Even did a classic dynamic programming one with a loop to reduce time from overhead function calls

Hi! Could someone please explain. Does kata consider the cache to be shared across multiple fibonacci(n) calls or not?

To make things easy start solving this Kata from .from_array method)

Heh - I forgot the trick where if you set a default value in the function signature, the instance persists.

Thanks for the pointer