CodeKata | Learning Scala | Build Tool library

Let's say v.length is 5.

You want to execute the following loops passes:

1. i=0, j=1, k=2
2. i=1, j=2, k=3
3. i=2, j=3, k=4

But that's not what you're doing. You have j and k change semi-independently of i.

1. i=0, j=1, k=2
2. i=0, j=1, k=3
3. i=0, j=1, k=4
4. i=0, j=2, k=3
5. i=0, j=2, k=4
6. i=0, j=3, k=4
7. i=1, j=2, k=3
8. i=1, j=2, k=4
9. i=1, j=3, k=4
10. i=2, j=3, k=4

To get the desired outcome, you should only have one loop. You can derive the other values from the loop variable.

You could derive j and k from i as follows:

• You don't need a list, you could do it with O(1) additional space.

• It is likely that not your implementation is the problem, but -1. Why? It is infinitely odd, because (-1 - 1) / 2 = -1. Interestingly this is the only such number, all other negative numbers have an oddity level of 1.

• For positive numbers you are basically counting the number of consecutive bits set to 1 from the right, so you can work with masks to be even faster.

This is how such an implementation could look like, assuming 32-bit integers (sorry Java):

Part of the reason is that the queue code is way faster than the List code, because queues are optimised for deletes due to the fact that they are a circular buffer. Lists aren't - the list copies the array contents every time you remove that first element.

Change the input value to 72307000 for example. On my machine, the queue finishes that in less than a second. The list is still chugging away minutes (and at this rate, hours) later. In 4 minutes i is now at 752408 - it has done almost 1% of the work).

Thus, I am not sure the queue is less memory efficient. It is just so fast that you run into the memory issue sooner. The list almost certainly has the same issue (the way that List and Queue do array size doubling is very similar) - it will just likely take days to run into it.

To a certain extent, you could predict this even without running your code. A queue with 7230702951 entries in it (running 64-bit) will take a minimum of 8 bytes per entry. So 57845623608 bytes. Which is larger than 50GB. Clearly your machine is going to struggle to fit that in RAM (plus .NET won't let you have an array that large)...

Additionally, your code has a subtle bug. The loop can't ever end (if n is greater than int.MaxValue). Your loop variable is an int but the parameter is a long. Your int will overflow (from int.MaxValue to int.MinValue with i++). So the loop will never exit, for large values of n (meaning the queue will grow forever). You likely should change the type of i to long.