Agreed

The author hasn't been on CW for some years now, so I've more or less "taken over" this kata. I've added 10 random tests.

Yup, I had similar bug in my encode function. And if it wasn't for you, I would have never thought that this test might fail because of encode, not decode.

SagePtr, this hint help me a lot, thank you !

+1, it should be this test: "\xFF\xFF\xFF\xFF" = "<s8W-!>"

Also, I believe This is rather arbitrar approach should be This is a rather arbitrary approach (added the word a and a -y).

Thanks, I updated it.

I agree: Katas like this teach you a lot. This is not a 6th kyu kata imho.

The differences are subtle, but this one is actually a bit easier than the other (simply because you only have to solve the one step). It made mine a one-liner.

This one is also well written, so maybe it can stay, too.

I searched for many keywords, including "Look", "Look and say", and even the sequence's OEIS number...

They're not identical at least; I can edit the description to clarify the difference. If there's a consensus that this one should be deleted, that's fine.

Just noticed that the other kata has the additional "brief" argument. This may be enough to consider them 2 different kata. What do you guys think?

What a dilemma we have here. Both have their strong points and they were both created very recent of each other. We are looking to make some changes soon so that each language of a kata can have its own author (preparing for the ability to have others add new languages to existing kata). When thats done I could possibly merge the coffeescript and ruby versions over to the other kata so that both authors get credit.

Hello, thank you for your feedback. I implemented more test cases + random tests on 500 elements arrays. I was not so sure about how to implement the random test cases though so I "improvised" a little solution() function directly in the test cases. I supposed testing assertEquals(maxContiguousSum(arr), maxContiguousSum(arr)) was ridiculous.

Overlapping doesn't count, so that would be false.

Good point. I've added a simple .toFixed(10) to compare the numbers, which seems to cover your solutions.