I can see the idea behind that, but it does break a lot of potential mathematical implementations of this problem - the greatest common divisor approach no longer works, for example. Would you be willing to reconsider that requirement (or just re-write the tests so that it doesn't matter)?
Aye, could be. I called it 'identical' as a word choice rather than an indication of its technical content. I think it's fairly clear from the description what you need to do.
Existing tests provide enough coverage. More would be nice but are not currently essential.
I can see the idea behind that, but it does break a lot of potential mathematical implementations of this problem - the greatest common divisor approach no longer works, for example. Would you be willing to reconsider that requirement (or just re-write the tests so that it doesn't matter)?
In the Python version, the test cases for "Extra zeros handling" are incorrect.
The test submits
01110asbits. With extra zeros stripped, this is111. The sample rate here can only be one per dot. Hence, this message is three time units long, and the signal is HIGH for all three time units. This represents a dash. According to the Morse code standard, a dash is T: see https://upload.wikimedia.org/wikipedia/commons/thumb/b/b5/International_Morse_Code.svg/450px-International_Morse_Code.svg.png. These tests expect E, which is instead a dot.The same issue applies to the other test case (
bits=000000011100000): Got T, expected E, but T is correct.Link doesn't list any open translation forks. Did you publish it?
Done, thanks.
[status-norepro]
Does your browser support
let?Aye, could be. I called it 'identical' as a word choice rather than an indication of its technical content. I think it's fairly clear from the description what you need to do.