Your implementation of the random tests makes it possible for the function to be passed no arguments, which contradicts the description.

The function is annotated with tuple[int, int, int, int], but you expect a list[int] in the tests. Please change the tests to expect a tuple.

These tests do not compile. Try to figure out why.

the code has the words for, break and continue in the comment

This comment has been deleted.

Python translation

Python translation

fixed

Hi again,

The actual input(s?) are never discussed in the description. The user shouldn't have to guess the spec or enter the trainer to know about this.

Yes, I got that part. The problem was that with a not large enough tolerance, accidental "not optimal cases" could sometimes weight too much. But now it looks ok, so "anyway".

The reason I do tests like this is such that if your solution does worse on some tests, but does better on others, it can cancel out.

I thought multiprocessing didn't work here lol, guess I was wrong

Well, I didn't realize I was working on an updated version of the tests. My solution consistently passes, now, so in the end, I guess the tolerance is actually lax enough.

ok, look here, please: https://www.codewars.com/kumite/67928fddb47458a990ee6388?sel=67991f05b3e3da841ece0758

• full cost of a path is on average around 4400, for 150 tests.
• both implementations are yielding close values in any case, since the max diff is generally less than 500
• the score is computed using score += expected_cost / actual_cost, which seems wrong to me, because an accidental huge diff will weight more on the final value while, in the end, what you actually want to test is that both solutions are randomly behaving "the same" (aka, sometimes exp is bigger, sometimes it's smaller).
• note that on 150 tests, there are generally like 140 where both approaches give the same result. That seems to me a way more efficient measurment to try to guess if both approaches are compatible or not.
• If I'm not mistaken, since score += exp_cost /actual_cost, the value increases when exp is worse than actual. Funny thing is that the test is (t-score) <= 0.925 * t which means the actual solution has to be better than the expected one to pass the test. No? Nope, that part is ok, I'm just too much tired.

In the end:

1. The testing process is just totally wrong not lax enough, as far as I can tell. A better measurment would be imo to do the following:
   • score += 0 when both costs are equal
   • score += 1 when actual is worse than exp
   • score -= 1 when actual is better
   • at the end, check that score/number of tests in the batch is low enough. The big question being "how much?", but at least, here, accidental huge differences between results won't wheight on the score.
   • make sure solutions that give better results consistently may never fail the tests.
2. The score value in the assertion messages is not very informative for the user, since it's never explained what the value actually means.