The details in the description are not enough to code these classes so they work all from the get-go.
There are a ton of tests, and they're necessary to be looked at in order to fix everything.
A little bit of bruteforce will probably be needed to figure things out.
I wouldn't want every kata to be like this, but I think this one is a great change of pace; more focused on coding, less on maths themselves.
Definitely a fan of the OOP kata series!

I'm insanely glad someone else had a go at this sort of an issue. I most certainly agree with you that this would in itself be a 1 dan problem if you couldn't look at any internet sources.
There are a ton of problems on CodeWars, and especially the 3 kyu + levels, that are 99% Math focused while using 7 kyu language functions.
Problems like these, which boil down to recursion with O (log n) algorithms are simple to code, but notoriously hard to understand.
I do, in one hand, believe that there are people who actually do these problems on paper, write their own test cases and everything.
But then again, most of the people here, even 1 kyu or 1 dan, don't really know Maths that well, especially not Maths needed at that level and knowing how to apply them.

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).

Users can see only long, but this does not mean 32 bits, because its platform dependant. In the worst case, you risk a fact that you generate 32-bit values and pass them to a function excpecting 64-bit input.

Well I don't necessarily hope for people that are 7 kyu to understand what int32_t is, so the chances are astronomously higher that the user will be familiar with long instead.

That risk is like throwing 0.5f into a function that takes double. In any case, good thing is that we are NOT losing any of the numbers. Long is 32bit in the LP32 data model, and only 64bit in LP64 data model although it's much more recommended to be using long long at that point (just for the sake of backwards compatibility).

Hey. The tests use int32_t, but the solution uses long as arguments, just to indicate to the user that the values might be large (i.e. 32bits).

But how does this help the user? User cannot see that int32_t is used, because they cannot see the test suite. Users can see only long, but this does not mean 32 bits, because its platform dependant. In the worst case, you risk a fact that you generate 32-bit values and pass them to a function excpecting 64-bit input.
It's just a kind of coincidence that currently both int32_t and long are 32 bits (if they indeed are).

I haven't found a way to figure out how to DM the author or anything yet unfortunately.

Unfortunately, you can't do that easily :( There are some ways to force a notification, but they are just workarounds.

Hey. The tests use int32_t, but the solution uses long as arguments, just to indicate to the user that the values might be large (i.e. 32bits).

The print was left in without any reason - I just forgot to remove logging. It was just so I can check everything is working correctly and as it should.

"Whether author and translator decide to use the technique is up to them. It started as a suggestion from my side."

I would honestly love for the author to chime in and consider this solution too. I haven't found a way to figure out how to DM the author or anything yet unfortunately.

My bad, sorry!

• tests use int32_t to generate values, but solution uses long as arguments. These two should be brought together. I am not sure which one is better, but since kata is about bits, I think I'd go with int32_t.
• I am not sure if tests should print anything, I would remove the printing statements, users can always print inputs if they want to.

But if you are going to keep them (and I can understand why), they should be moved before the assertion. Otherwise, when assertion fails, the printing does not happen and user is left misguided with the failure message preceeded by the previous, successful test case.

Besides, printed message is not very meaningful, just two random numbers and a random 0 or 1 at the end: it should be explained to the user what the numbers are and what does the third printed value mean.

I see this in the python test cases: (16, 8 -> False)
Why is this False?
16 => 10000
8 => 01000

(also I don't see why C++ tests need to be different from other languages)

They do not have to. It was just my proposal to create tests which, as opposed to other languages, are not crippled in range and balanced better. Inputs generated by "totally random" generators have poor coverage and are unbalanced. Here is my attempt at creating and educating users how to create random generator which does not just "spray and pray" to produce something useful, but where randomly generated test cases are actually meaningful.

Currently, test cases from other languages are limited to values ut po 1000 or 2000 without any particular reason, and 80% of test cases leans towards true scenario but even without guarantee that any false case will be generated (luckily, still very likely to have at least a couple of them). Ideally, C++ test would not be different from other languages, but tests for other languages would also be improved in terms of coverage and balance.

Whether author and translator decide to use the technique is up to them. It started as a suggestion from my side.

"(also I don't see why C++ tests need to be different from other languages)"

Well, they don't need to be necessarily. The problem here is that hobovsky said true pairs are generated about 80% of the time using just random and evaluating the outcomes - so we're kind of trying to force 50/50 pairs here.

Hope that makes a bit more sense. Also, Check out this kumite, I did - and will implement this here.

.. did two comments here just get removed somehow? one from hobovsky one from me? I see mine on the front page, but no longer here.
So confused.

edit: Oh, no, after posting this, they show up again. Because that makes sense.

          int32_t a = rand()%20000;
          int32_t b = rand()%20000;
          while (... == false)
              b = rand()%20000;

if a only has 1 bit, that loop will go on forever

(also I don't see why C++ tests need to be different from other languages)

Check out this kumite: https://www.codewars.com/kumite/5fc99c9c78ee4c002637cb86?sel=5fc99c9c78ee4c002637cb86