Nice! taking notes for shorter lines!

Gotta say, I don't really understand why this works the way it works intuitively, but people complaining that this isn't "best practice" or "uh muh readability", "maintainability", or "what about junior devs":

This is a code exercise, not production code.
Yes, in production you'd want better guard rails and input validation, and yes, you would want this documented to explain what it does. And yes, you'd need to validate that the ouput is sane since multiple odd occurances throws the math out the window lol (so maybe that would make this solution invalid for production as extra compute might outweigh the space benefits).

However, as a general point you shouldn't sacrafice performance of something so simple with a very clear objective to write more convoluted looping code that will take a junior some time to parse anyway.

If you know a clever way to do something that's performant, is little code, and achieves a clear focused objectives, you shouldn't dumb it down because someone might not get it. Let them figure it out, and learn, and make sure the rest of the codebase isn't impacted by someone not understanding a bit of code in it.

Well I call it Best Practices.

Random tests added in this fork

directly

fixed

fixed for javascript, and available in python

me too))

Thank you oh so much for this meaningful error message:

Forbidden Words
The body of your code contains forbidden word(s).: True should equal False

The Issue label means: "something seems to be wrong with the exercise mechanism, the tests, or the description." If you're asking for help with your approach, use the Question tag.

Then, for a question, "what did I leave out?": you don't clearly describe what your difficulty is. Without being certain of that, I will point at the sample tests (in C, Java, Ruby, etc.) which show that the correct result with input "" is "".

i liked this pin

Funny one of the series.

lol

That's brilliant! I would have never thought of that myself!