• Please do away with the using namespace std; it forces that style on users who don't want it.
• The fixed tests should also be in the submission tests too.
• Minor stylistic nitpick, but scoping every assert statement in the fixed tests is unneeded and might be a source of confusion.
• The input sizes are determined at compile-time. This is not random
• The usage of std::linear_congruential_engine here is overengineered; with this config, it generates a linear sequence with a step of 3 starting from 1 (exclusively). Every single test run would generate the sequence (4, 4+3, 4+3+3, ...) without fail. This is also not random
• All the values in the generated b are from a. This doesn't test how the user's solution handles values in b that are not in a. Also, this means that b preserves the order of a which reduces the randomness further.
• This point is more general, but I really feel like the structure of the random tests can be massively simplified. Between the usage of std::linear_congruential_engine, the need for explicit moves, the magic numbers (like LN/4) and the reaally long function, I really feel like some parts can be refactored, some removed, and some restructured to make the random testing strategy more readable.

Trying it in C++, having a problem with the invalid cases...

In the final fixed tests Invalid_Shuffle_Control3
Entry vector is (10,20,30)
chunk size is 1, control is also 1 (000000000000001).
If I follow the description:
Chunk size is 1, and all bits to one, so I should zero the first entry of the give chunk.
Then I go to the second chunk, etc etc...
Thus the result of my solution is => ret=1, vector {0,0,0}...

But it is expected to have an invalid control ????
Expected: equal to ret = 0, vector = { 10, 20, 30 }

Cannot figure out what's wrong ??

Sleek

This approach uses Python, that's not optimal in terms of speed.

I find this type of codes a bit harder to read at the first glance. Maybe because I'm still a newbie?

I think your previous solution was more efficient, this one keesp repeatedly searching the lowerbound, the prior compared as interleaving

This is the way, I would only change a few minor things

Nice, very neatly done. I wish I would have seen it like that, your solution made me realise it's so much more about problem solving that it is about "code" and syntax.

Bello !

You're absolutely right, but the original one explicitly excluded std::merge :)

The description should make clear that the final chunk is implicitly padded with zeros if it's length is less than the chunk_size. This can be figured out from the sample test cases, but it is difficult to see because there is also the zeroing behavior from the all-ones index. (I initially thought that the final chunk's actual size is used for it's chunk_size, since that leads to the same behavior in certain cases)