Haskell: codon (a function, codon :: Codon -> AminoAcid)

JavaScript: codons

Python: codons

Ruby: $codons

🤖

• Scrutinized tests

• Added useful assertion messages

• Used lodash functions

Rarely used synonym for XNOR.

.

Kata author inactive.

Fork here:
https://www.codewars.com/kumite/66cfc32158ca25adbd4046c4

Which addresses the following issues:

https://www.codewars.com/kata/5708ef48fe2d018413000776/discuss#66ceed4f35f801ce5b2114f0

https://www.codewars.com/kata/5708ef48fe2d018413000776/discuss#64a00e06dddc25005edfaf86

The issue tag is for problems with the kata itself, not for problems you're having solving it. Have you tried printing out your variables at critical points at checking them against your expected logic?

Fair point. I'm being a bit idealistic.

Fork here which addresses the following problems in JS:

1. Test max now matches description
2. Initial solution function signature fixed
3. Node version updated to 18.x
4. Test library updated to chai
5. Tests are no longer in code-golf style formatting (why was this even a thing?)

Nice kata. Perhaps it was just me, but I think I've solved easier 2-3kyus lol. Suprised at the difficulty.

Random tests in Python do not contain any loops or no-ops, therefore only testing a subset of the specified behaviour.

Python fork which implements better random testing:
https://www.codewars.com/kumite/66c8182e4d7ff9aec7c3b877

If approved I'll port the changes to JS as well.

I think you've misunderstood the kata. If a ball goes from 10m, down to 0m, then back up to 10m and there is a window at 5m the mother at the window will see the ball twice; once on the way down, once on the way up. This kata is not about counting the number of bounces.

If you want to raise an issue in the future please:

1. Check carefully whether the issue is actually with the kata. 87,000+ people have completed this one. What are the chances they all got it wrong?
2. Note which language you found the issue in
3. Include more info to help others reproduce the error

Depends how high you put the bar. If you don't use more memory than necessary, I say you qualify. Nothing is keeping a normal iterator from keeping, possibly huge, state either.

Fun kata, but I find the first part of the description a bit amusing.
Every solution I've looked at (including my own) does not actually contradict what Mozilla said, in my opinion.

It might be obvious from the syntax but it's best to say which language you're working in so people can help debug.

It appears to me that the Scala solution is correct.

For Seq("B", "B", "A", "A", "A", "B", "A") I would expect:

• Pop "B", "B" from index 0 => Seq("A", "A", "A", "B", "A")
• Pop "A", "A", "A" from index 0 => Seq("B", "A")
• Nothing more to pop; return Seq("B", "A")

when I test the reference solution popBlocks(Seq("B", "B", "A", "A", "A", "B", "A")) => Seq("B", "A")

Do you expect something different? If so, what?