This teaches some valuable lessons. Unfortunately, it seemed to be primarily through frustration. Not the best teaching method. Some more rounded sample tests hinting at the esoteric quirks being highlighted would be a large improvement. Where there is a whip there is a way, but gentle encouragement is a better choice IMHO.

I like it. Perhaps just a little to clever for its own good? As code-fu it's great though!

I like your clarification of variable names too!

I hadn't concidered Arphox's comment at all (thinking they were givens I couldn't change), but they're right. Unless stipulated in some sort of weird requirement, the parameter names are up to me as well.

Either way, such additions will be removed by optimizations, so adding code like this to benefit readability is always a great idea.

I actually like this solution very much.
In the real world, code efficiency is FAR less important than readability unless the customer raises a defect that it's too slow. Seriously.
I glance at this in passing and know it's something to do with number parity.
The fancy solutions are better if speed is a concern, perhaps.
I'm long past my days where I had to produce an esoteric single-line solution all the time.