I don not understand why come here to practice and answer just by using built-in methods.

Yeah, I guess the author approved it. He also is changing the description as I can't alter it and save.

Looks approved to me. Apparently he did, or you managed to self-approve anyway.

No, also real, actual zeroes. 0 has length 1, which is not consistent with some ways of doing things.

Yeah, I didn't know what would happen if the number wrapped so if it went over I thought it could fail the comparison.

It won't wrap, it'll just lose precision.

All changes made.

I can't edit the kata, I guess belenox has to approve this one.

Testing is so much easier with Haskell.

Ideally I would make test cases with things like 10 and 11 guaranteed. But I just printed a few runs to the console and they happen all the time if you just force the zero's so I think it is ok.

And test with zeroes.

Yeah, I didn't know what would happen if the number wrapped so if it went over I thought it could fail the comparison.

Oh. [Suggestion] Set the JS version to 8.x instead of 6.x.

That looks good!

You don't actually need to compare against a stringified Number.MAX_INT; JS will compare them as Numbers just fine, with a loss of precision, but that won't affect the outcome of the comparison. The problem is Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2, but if it's bigger, it's bigger.

That solution is clever BTW. It's about two orders of magnitude shorter than mine. :P

The instructions tell you about the partition method.

This is obviously reading the instructions.

The example even used partition with a block...

Yeah, U are right

In any case wrapping it in this way would be consider a horrible indirection and a bad practice. Would be better to just use Enumerable.max_by directly. It also breaks the ruby spirit of having all messages related to a class as methods of the same class.

Yeaaah! Nice, man. :)