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.

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

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

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.

their length differs only by one (a small fraction of their length), but one group is supposed to represent 1 time unit while the other 3 time units

Well, the idea is to calculate the statistics of fragment lengths and define the border between 1 and 3. Then everything below that border goes as 1, and everything above goes as 3 (or 7, but that's another border). Another option would be "if there're fragments too close in length, consider the message undecodable", which is not that funny. :)

I think many different applicable methods would have to be really fine-tuned to correctly decode a message this 'noisy'.

Well, what I did is I created a solution as good as seemed reasonable and then added noise to the last test message up to the point that more noise would produce actual mistakes in decoding. So this particular message is as noisy (and though tough) as it gets, to make those who attempt it to check their algorithms really carefully.

Probably, it's a bit too tough, I may agree - judging by the fact that the kata is still in beta. :)

I wonder if you'd get the same result if you'd decode the message in reverse order for example.

decodeBitsAdvanced(bits[::-1])[::-1] == decodeBitsAdvanced(bits)

This if for my solution and for the last test data. :)

In fact, for a proper solution order should not be significant, only the lengths of fragments and their numbers should.

Part of the problem is to figure out how to deal with the problem. Though, sometimes the servers are just busy.