• n should be std::size_t, not int. This change would remove the need for the odd cast in the if. Variables throughout your code that are supposed to represent an index or a size should be std::size_t
• Your reference solution is exposed in the global scope. Please move it to the private section of the Describe struct, and keep the existing code in a public section. Here is an example
• All the headers are missing. You need to #include: <vector>, <cstddef>, <random> (more on that below)
• Error feedback is missing. With each assertion, you should provide an ExtraMessage. Many examples on how you can do so in this example suite
• Do not use the C-style random generation utilities. Use the utilities from C++11's <random> instead. Link to the relevant docs
• For appropriate semantics, accept the vector by const std::vector<int>& instead of by value
• The default setup should compile, therefore add a single return {}; to the body of the solution setup
• Remove the unneeded default Codewars TODO comment on top of each snippet. It's bound to confuse some solvers
• Description mentions a reference but doesn't include it. Either that line should be hidden for cpp, or you should pick a method to showcase. The issue is that there is no canonical way to slice a vector in c++. You can kinda do it in like 9 different ways.

Yes, it is more clear for me now.

oh I see, is it ok now?

I read it as "no (repeating or zero integer roots)". Also "zero integer roots" reads like "it should have at least one integer root".

I don't get it, the current description already states "integer roots"

Description was not clear for me. I would suggest to change it to

Let's call this polynomial compact if it has only integer roots which are non-repeating and non-zero and ...

Currently it sounds like real and complex roots are ok.

Try not to use floating point arithmetic.

Guys,
I thought I understood the problem well and found the proper solution to it.
(JS)
At that, while my solution always passes complete set of "small" random tests, it fails the 1st "big" test.
Can there be something wrong with JS "big" tests or I am really so stupid on Friday morning :) ...

done

upper bound lowered

I published a fork, but please review it, there are a few changes I'm not too sure about. And yes, I couldn't make a fork because I was on my phone.

I made a fork for the Python test cases.

• Added more fixed tests, with hardcoded solutions
• Separated the tests into Small, Medium and Big for both fixed and random tests.
• Reduced the amount of random tests from 1000 to 150, 1000 felt like it was too much.
• Provided the input upon failing a test.
• Removed the test indexation, for example, failed on test 324. I didn't see a good reason for it, especially with fewer tests.

Any of these changes can be reverted, so be sure to let me know if you disagree with any of them.

JavaScript: either BigInt should be used or the input upper bound should be lowered in random tests.

Feel free to suggest changes or a fork. Just make sure to keep test output a black box.