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.

lol That's so funny. Brilliant and unhinged.