The python translation's random tests can test with zeros, but don't always, allowing solutions that don't handle zero correctly to pass. Zero inputs should be tested explicitly in the basic test cases. Fix

Yes, my solution passes now. Thanks!

Well-composed. Nice names. Very readable. 👍

This is still a problem. Example solution that should not pass.

This is still a problem. Example 'solution' demostrating the need for random tests

Size of huge tests for Rust has been slightly reduced. I will mark the issue as resolved, and I would kindly ask you if your solution passes consistently now.

I'm the author of the translation. I tried to adjust the tests trying to have similar execution times using similar solutions in other languages, but this is not perfect science and it's hard to have something balanced. It's possible big tests are too tough and don't allow some legit logarithmic solutions to pass, which is, IMO, not the purpose of this kata. I published another version reducing the size of the big tests (passing from ~80k points to ~50 k points) and your solution is now always passing apparently (at least the one I have tried, which is I guess the last one you have intended to use). The new fork is there, in case someone feels like approving it: https://www.codewars.com/kumite/62894485b7d077b3b3a889e7?sel=62a080cf0e41760016141810

Thanks for your feedback.

Still, I would believe you are missing something in your solution because Rust full test suite with reference solution run very consistently with times between 5.5 and 6 seconds.

As far as I can read Rust, huge tests is 5 cases with ~800k points each. Maybe you still need to shave off some time wasted for unnecessary calculations, somewhere?

I think the Rust huge_random_test input sizes are little too big: Two different O(n log n) implementations I tried both time out, but look very easily distinguishable from a O(n^2) implementation timing-wise:

Yes I know and for new katas I have changed my mind. Many C++ katas are written as classes...

In C++, there is no reason for this to be a class member function. Have the user declare a bare function.