Great. Ty again for the help!

Right, I did that and republished just now. Now outputs are no longer "truncated". I'll come back in a short while to make sure outputs are still correct and mark as solved if that's the case.

I noticed our solutions produce different outputs, so I'll check wether that's a mistake in mine or yours and send an update when done.

Thanks again.

Excuse me, I overlooked it. I unflagged my response since it doesn't really represent a relevant spoiler to the solution, at least in my opinion.

You're right: employing decimal.Decimal instead of float fixed the precision issue and confirmed your output (at least for the test case you presented).

Reference solution has been updated and tests have been slightly adjusted to take into account the small execution time increment caused by the improved precision.

Thank you very much for pointing that out! Please confirm that the problem is now fixed so i can mark the issue as solved.

Done: cut down tests to a third of the former amount, resulting in an execution time of 3.5s (see updated "Performance" paragraph in the description).

The tests' upper bound for the goal parameter has also been reduced, since it didn't really provide harder test cases - only bloated the tests amount.

Thank you for your input!

Short and sweet!

Thanks!! Translation approved

Do you think I should raise it to 3kyu?

I think it's best if I remove it then.

Yeah, that's really weird. I tried running your solution and I couldn't get the print statements to work (except for the first one, for some reason. If I remove it, nothing is printed at all). I read the test cases and found nothing that may prevent a print statement from executing... not sure what's up.

True, it's quite strange... if I were to take a guess, I would assume this is a symptome of trying to print a dict of this size: while it's useful to see the example tests' ingredients to find the cause of any bugs, it's pretty much pointless on the performance tests, because there's too many ingredients to check.

Actually, it's straight up counterproductive because print statements impact your performance: if I were you, I would remove print statements when I'm going for the submission rather than the example test cases. As stipulated in the kata description, example test cases should be enough to confirm your algorithm is correct, so you shouldn't need to "debug" performance tests.

tropical paradise, performance hell

In Python, if the user's solution modifies traffic, test cases break. In the tester code, pass a COPY of the list to the solution with traffic[:] to fix this.
In the meantime, I managed to submit my solution by copying the traffic list like this: t = traffic[:] and using my copy to solve the problem.

I added a test that causes their solution to fail consistently (sorry mednoob blud)

True, thanks for the tip!