The third problem is looking to partition the entire sequence of numbers into contiguous subsequences, all of which add up to the same sum. In other words, if the list were 23415, you subsequences could be 23, 41 and 5, all equaling 5. But the subsequences have to use up the entire string and they can't overlap.

They can't overlap! I don't think the problem specifies that?

You have to interpret "break up" to mean "non-overlapping" to claim that the problem means what you're saying it means; I found 341 "contiguous subsequences such that the sums of each of the subsequences are equal", but they overlap.

(If you had said "partition" I suspect I would have got what you meant)

Contiguous implies non-overlapping.

Did anyone else do that one without writing any code?

You mean with smart guessing? That's no fun!

Yeah. It took me three guesses to get it right. :)

You didn't need 3 guesses. The sum of each partition has to be a factor of the number. In particular the sum of the first partition has to be a factor. Then the second. That already gives you the answer I think.

Sure, but then I'd actually have to look at the numbers. My solution works without having to download the file! ;)

> #pip install python-levenshtein > from Levenshtein import distance

That doesn't seem in the spirit of the challenge.

Why? It's not hard to write a quick and dirty levenshtein function, but when google gets it for me in 1 minute, why do it?

edit: just for fun, as a one-liner:

    def levenshtein(a,b): return sum(x!=y for x,y in zip(a, b))

edit 2: and just to clarify, I know this fails if the lengths of the input strings differ, they were guaranteed to be equal in my code.

Can you do it in linear time in the length of the input?

Find an actual (amortized) linear time implementation for this question in the following gist:

https://gist.github.com/1026638

It's not hard to prove that that's impossible

It's possible if RAM isn't a constraint, using a bitset of all possible five-letter strings. The bitset would take up 4G of RAM (128G for extended ASCII, more for unicode).

In practice, that would actually be slower on this input, because of the cost of initializing the bitset. But that is not dependent on the input, so computational complexity is unaffected.

edit: Removed description. Yes, you're right, you can't even look at the whole input in constant time.

This is a misunderstanding, you must have answered to my reply after ithayer edited his comment, the initial comment said "constant time".

Didn't understand what you meant, care to elaborate?

:) I meant linear, but I'd review a proof :)