I think this is relevant to this issue that I just noticed.
In the expression below, I believe the multiplication is being handled before the division, even though the division is to the left of the multiplication. (I feel like we are expected to think of pemdas as p-e-m-d-a-s instead of p-e-md-as, but this is not how tings posa werk...)

The following is untrue in Ruby because of INTEGER DIVISION:
Expected: '2 / (2 + 3) * 4.33 - -6' to be 7.732 but got 6.0 - Expected: 7.732, instead got: 6.0

PROOF:
2 / (2 + 3) -> 0
0 * 4.33 -> 0.0
0.0 - -6 -> 6.0

What is your suggestion?

Closing.

Ok,thanks

could your explain the meaning of loop

I'm closing this issue as it seems no longer an issue. :)

I repeat: even if the function has a single line: "return BigInteger.ONE;" the tests still time out.

How can I unconditionally return number 1 more efficiently than that?

that would have been an issue with your solution being inefficient.

After months (if not a full year) of having a correct solution in Java, I was finally able to submit it without any timeout on http://preview.codewars.com/

On the normal site, even a solution along the lines of "return 1;" would timeout.

There are no tests for the following requirement: "Operators are always evaluated from left-to-right".
Some of the solutions were accepted even though they evaluate "1 - 2 + 3" as 1 - 5 = -4 (instead of -1 + 3 = 2).

Congratulations! :) You're one of the very few who got this far. :)

Thanks!

Solved that, spending the whole day. Thank you for your explanation. I really liked your morse katas!

No, tests for this kata do NOT include noise, meaning any sequence of 1's is definitely dot or dash, and any sequence of 0's definitely separates a couple of dots/dashes.

All the complexity of this kata is concentrated on variating LENGTH of the tokens (sequences of 0's or 1's).

Haven't completed all the tests yet. I'm using kmeans2 from scipy package and almost every test is quite good. I've noticed the noise in the last test only after I actually printed the input sting. As I understood from this discussion (am I correct?), the sequances like "...0000000010000..." or "...111110011111111..." are noisy (these short inclusions is noise - not the dot). (*)

(if (*) is correct) Basically, in the description to the kate there are no words about noise so the solutions should treat every inclusion of 0's or 1's as some characters for the output. If it is so, you should include the warning about the noise to the description or get rid of it in the last test, because a correct solution which is related to the original description won't work with the last test.

agreed.