Збоченець

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.

Yes, you passed the tests, but there is no child/parent relationship or early return.

In the description links for the first and second parts are not working

https://www.codewars.com/kata/54b724efac3d5402db00065e - first part

https://www.codewars.com/kata/54b72c16cd7f5154e9000457 - second part

Congrats!

yes, they dont

https://www.codewars.com/kata/54b724efac3d5402db00065e - first part

https://www.codewars.com/kata/54b72c16cd7f5154e9000457 - second part