I'm getting confused here as well - I don't see a test case you mentioned :) maybe you have edited it yourself in your test suite by accident?

Oh, and 169/1364 = 0.123900293255... and not 0.12390 :)

Well, 1.(9) = 2 and 0.123(9) is, in fact, equal to 0.124, while 0.12390 you suggested is 0.000(9) less :)

I think you don't really understand repeating decimals. Please refer to e.g. wikipedia: https://en.wikipedia.org/wiki/Repeating_decimal#Converting_repeating_decimals_to_fractions

I wonder why you call objects "hashes". At first, I was really confused how should I calculate a hash representing a result, and only example test cases explained to me that you somehow mistake objects with hashes. Maybe you meant something like hashmaps (which, in fact, is similar, but not exactly how JS represents its objects)?

@EricFreeman - I see this was a quite long evening, since I've just uploaded solution that uses multiple regexes :)

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.

This kata is strictly about the algorithm, not some language features. Hence - why not? You're very welcome to translate it to Java :)

@CodeMonkey25 - thanks! I had exactly the same issue and your suggestion greatly helped me with finding the bug - maybe it was similar to yours :)

I fixed it by rounding values in my result, as I found in comments below. It works, since whole result is printed out to console for debug purposes, and if not rounded, many redundant decimal digits are printed, overflowing the output buffer.

I'm not marking this issue as fixed, since the kata should handle it properly itself.

Max Buffer reached: Too much information has been written to stdout.

This problem stil occurs for the random image.

Yup, noticed it just after posting mine ;)

I've been trying to fix this spelling for 5 days now, and while I had no problems with JS, re-publishing Java version does not work for me. It just hangs forever and only telling me to wait.

You're right - well, English is not my native language, and it seems I was always wrong about this word :)
Thanks for JS solution, however I suppose I will have to invalidate others' solutions in Java to correct this missspeling :(

Coordinates used in p/g operations need some clarification. I assumed that upper left corner would be [1, 1], which made my code fail unexpectedly upon submission, since it was [0, 0]. I agree this may be obvious in programming world, but could be clarified anyway ;)