That's clever, but damn is that going to be tough to debug O_o
Can you explain it?

Needs more test cases (at least in Java). My deliberately-bad solution passes the random tests by luck (occasionally).

I like how succinct and readable this is, but if you're going to do repeated string concanetations it's good practice to use a StringBuilder. Otherwise, this is great ^_^

I work full time, hence my intermittent replies. I like the idea of 50/50 generated test cases, but I also don't have the time to implement them. If a mod wants to approve changes on my behalf, I'm happy to forgo any kind of ownership (this Kata was authored years ago when I had way more free time).

Fixed

The reason I included the "positive" clause was to avoid confusion around sign-tracking bits. So changing descriptions to "non-negative" would be the easiest solution.

Honestly, I don't actually remember why I limited numbers to 2000. My best guess would be that once they got much bigger, the odds of 2 or more shared bits became too high. hobovsky's suggestion of directed-morphing of random numbers would fix that issue.

I don't have any C or C++ experience, so someone else will have to fix issues 1 and 2. How do you suggest you randomise a test suite, while avoiding bias, when the average pair of numbers should (in theory) share 50% of their bits? (I'm asking a legit question, not being a facetious twat)

Thanks, and sorry about the confusion. I've never had people translate my Katas before, and now I'm juggling conflicts and updates and translations all at once.

My mistake - I've never had people translating my Katas before. It should be approved/forked

"Description cannot be approved, recent changes from related record must be merged first."

I've had this issue before, the only work around we could find was creating a new translation from scratch.

@rowcased pointed this out too. I've put in a fix that should prevent this from happening.

"Description cannot be approved, recent changes from related record must be merged first."

We had this on another translation... the only fix was to re-create the translation from scratch :/

I wasn't able to replicate this issue. Regardless, I've wrapped the sample solution in a bool() cast, so things should be consistent now. Let me know if it still misbehaves.

Approved