Hacker News Reader

Comment by llimllib | Hacker News Reader

My answers in 31 lines of code: https://gist.github.com/1025860

I am either misreading the third problem's description, or I have a bug I can't for the life of me see, because the answer my program puts out is not accepted.

View on HN

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.

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! ;)

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.

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

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

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

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

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

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.

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

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

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

https://gist.github.com/1026638

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.

Reply on news.ycombinator.com