The better answer would be: Forget the 7:3:1 ratio from previous problem, in this 3rd installment, the operators don't give a damn about it.

I was trying a solution that would calculate the ratio the cut-off point as following: sqrt(shortestDot * longestDash), where dashes have to be strictly higher. I considered it a good idea as it allows both dot and dash the same ratio of error.

But my simple heuristic with dividing the longest dash by two worked a lot better for the most part, and combined with a few more heuristics, I covered it all but the weird case where "1001" is supposed to mean ". .", quite inconsistently with the 4 kyu Kata. So I kinda gave up on trying a more interesting solution and I agree that this Kata could have been more interesting if the test cases weren't so strict in some rather ambiguous or straight out controversial cases.

Forget the 7:3:1 rule. There is a test where the expected outcome of "1001" is actually ". .".

Yet we are supposed to remember the map name from the 4 kyu Kata. Too bad it is not defined somewhere what you should forget and what to remember.

Too bad I haven't learned how the notifications work here just yet. I wrote the mapping myself.

Maybe if the name of the map was mentioned in the description or initial code (more useful than that weird JavaDoc), it would help, though I noticed that most people use MorseCode map, I suppose they found out in the 4 kyu problem or asked someone in the discourse.

Yeah. 5 years later, MorseCode is still not mentioned in description, and the code won't help you there, either. For people who only solved the 6 kyu and 4 kyu problems for other languages, that is a bit of pickle. However, you are also expected to forget the 7:3:1 ratio you learned in 4 kyu problem, as it doesn't quite work here with test cases like "1001" -> ". .".

The only problem I could think of here are the non-alphabetic characters. Some of them are not present anywhere else.

This should be taken care of by the conversion table that is available for you to use. But in some cases it is missing a handle. E.g. in Java, most solutions use MorseCode map even though it is neither named in description, nor imported or used in any other way in the initial code.

Yeah, jolaf. That would be great if all translations contained a table.

For Java, there is no mention on where it is. I didn't solve part 2/3 in Java, maybe the MorseCode map is mentioned there, somewhere.

I had to come up with my own table, because neither the Description had it, nor the initial code had any reference to it (e.g. import, or anything).

Sadly, the tests don't give any gratification for finding a way.

They only really give you reward for complying with the reference solution.

Which reads "1001" as ". ." rather than ".." which seems way more fitting the description of 2/3 part of series.

Yeah, giving up may be the best choice when it comes to this Kata.

The second best choice is to come up with solution that handles most of it in compliance with tests (I clearly name it as such, rather than correctly, to avoid some confusion). Then, you hack the remaining tests to pass.

Some of the test cases (especially the short ones) don't even respect the ratios mentioned in previous part of series.

As for me, I find no such explanation. Either there is inadequate polling rate, or a poorly trained operator. But we are still tasked to decode this mess.

Does this Kata really ask us to solve Morse code? Or, is there some mathematical problem that is carefully not mentioned in the description, and that is the real thing we are supposed to figure out here?

I solved the entire series (and I somewhat hacked this one). In the previous installment, I've read about the lengths of the signals as they should be:

• Dot and short break (that divides dots and dashes) should be of unit length
• Dash and letter break should be 3 units long
• A space between words should be 7 units long

Now, let's say that the sampling rate is 100 ms and the operator's dot is 110-170 ms long. Let's say that they are otherwise fairly consistent with the requirements above.

• A dot or a short break will give us 1-2 bits,
• A dash or a long break will give us 3-6 bits,
• A space will give us 7-12 bits.

Now, let's say there is some super fast operator with dots at 80-110 ms. This means that:

• A dot or a short break will give us 0-1 bits,
• A dash or a long break will give us 2-4 bits,
• A space will give us 5-8 bits.

Clearly, the polling rate is inadequate in that case, because some dots or short breaks can be missed.

But since "1001" should be read as ". ." — what would be the correct relationship between operator's speed and polling rate so that we are fully consistent with the description? Is there any such explanation?

I feel like this very Kata is a fraud that is selling me Morse code, but in fact it asks me to solve some math problem by trial and error. And as such, I am surprised it has rating above 70 %, I wouldn't give it even 30 % myself.

Wow, so many 1 kyu code warriors defending a dead horse here. Yet the tests are inconsistent with the description.

If the polling rate is 100 ms and the operator takes 110 - 170 ms per dot or short break, how can a 200 ms break be considered a long break (dividing letters) if it should be 3 dots long (which would be 330 - 510 ms]? Yet somehow, "1001" should be translated as ". ." as per tests, thus resulting into "EE" where "I" would be more consistent with the tests.

Yes, you can come up with a solution that passes the tests without hacking any leftovers, but it doesn't solve Morse code. It solves some mathematical problem that is carefully hidden out of the description so that people with at least Bc. of theoretical mathematics can figure it out.

How did you enjoy my solution? It seems that the formatter didn't.

I hope your mouse wheel is still alive. Thanks for scrolling this far :-P

This fork fixes a bug in Scala reference solution that sometimes produces a straight of size=4.