"It can lead to bugs that are difficult to spot."

But the exact circumstances where automatic semicolon insertion doesn't behave as one would desire is clear and well-behaved. It's not black magic as everyone is instructed to believe as if. Just like every other tools, use your tools improperly and you get bitten in the back. (e.g defining RegExp objects with global flag then use them repeated to test different strings)

Recommended reading:
http://inimino.org/~inimino/blog/javascript_semicolons

Mmm, the bitwise approach should perform much much more quickly than the various non-bitwise solutions proposed, right? String parsing is always going to be slower than bitshifting and masking. Granted it adds complexity, but I wouldn't say none is needed - if you're trying to jam as many of these transforms as possible into a cycle the bitmath will pay dividends.

I wonder if it would be possible to define kata using performance constraints. Obviously you couldn't do it in an absolute sense, as different machines would perform differently, but perhaps providing a reference implementation (say, using string parsing) and requiring that any solutions perform better by a factor of X?

Putting in that kind of constraint would not only encourage more efficient solutions but would also justify a higher kyu by touching on meaningful performance metrics as a requirement rather than a hypothetical.

ALL of the solutions submitted so far don't use bitwise operators, unless some have come through since I last looked. Honestly, I'm not sure I would ever turn to them for this; it's making complexity where none is needed.

I'd say this is, at MOST, a 6, since it requires string manipulation and then either base conversion arithmetically or by using the radix argument in parseInt, both of which you might charitably argue are a bit more complicated than the standard 7-kyu fare.

The problems are:

1. Bitwise operators definitely don't push a kata up to 3 kyu; take a look at all the bitwise-using kata to see how they've shaken out.
2. Your kata definitely has no need for bitwise operators. If the intention is that solutions must use bitwise operators, then you should (a) specify that up front, and (b) figure out how to disable all the non-bitwise-using methods of solving it (since there are a ton of them).