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.

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

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.

"(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.

Yeah the true number generator doesn't really work -> here's why:
If it somehow generates number 3 or some low numbers then the binary complement for example for 3 is 100, when multiplied by -1 it returns a value of 100, which has no common bits with 011.

I've modified the generator function, but this is basically back to square one since I had no idea in what way to accomplish what I wanted.

Esentially what I did is:

• Generate a and b with random - while loop until condition is satisfied to keep rerolling for b. -> true nums
• Do b = a & b-1, and if that condition again isn't satisfied then generate a random number between 0 and 30, and throw 2^that number (because then the bit will be something like 0b000100000000000000) -> i.e. only one possible bit.

Now this is a completely ridicilous way to do this, but my mind really doesn't work at 2AM.
For what it's worth, any normal solution should be able to pass these tests (with the given one taking around 3s for each run).

If you have a better idea to generate bits, I'd be happy to hear it.

Well, thanks for the quick reply.
Great to have someone around guiding me here - first translation I've done and it's been quite the experience.

I've taken notes and:

• I've added back the #include-s for everything that should be used in there (from what I see).
• Updated the vector to hold a pair which holds a pair and a bool :) - perhaps a bit more complex solution, but due to random_shuffle I've decided to do it this way.

" One important thing though is that your algorithm does not seem to generate invalid pairs with one common bit - am I right? "

No?
I've goten generated 7 and 8244 this time around (for false)

   7 - 0b00000000000111
8244 - 0b10000000110100

That's 1 common bit.

Hey. I've updated the solution.

• I've avoided using #includes at the start - since apparently they aren't even necessary

• Currently it generates a with random (up to 20,000 otherwise the numbers are too large and nonsensical).

• b is calculated with binary complementing and * -1 so the number isn't negative (that's for true pairs).

• After that a false pair is generated by making a be equal to XOR result of a and b.

• All those values are then put into a vector, and using the random_shuffle method from "algorithm" library, they're "randomly (using the seed before)" reorganized and the vector is then iterated through, calculating the solution and comparing to the user recieved one.

Hope to get this re-approved. If there are any further remarks, please let me know.

Hey! I definitely could. I was looking at the C# implementation when I was doing the translation.
In the C# translation (at the time of writing mine), the randomization was limited to 2000.

Perhaps the original creator of the kata can elaborate more on why is that?

I have no trouble in changing it to larger sizes, or even using different methods of generation.

Also, sidenoted question,

• is there a particular reason why C headers shouldn't be used?

Republished the edited version.
Try it now, it should work

C++ translation rekumited.

Has 50 false & 50 true random tests.

Doesn't really matter since if the if-statement executes, it will return from the function at that point.

If you have 20 customers and 1 guy - iterations of outer and inner are 20.
if you have 5 customers and 100 guys - iterations of outer and inner are 500.

So simply O(customers.size() * n).

The thing you have to note here is that n is "int", so the solution is more than acceptable.