C (also the case for the previous 32-bit signed comment)

Perhaps 'n' should be revealed on a failure in the random tests?

When you get a random test wrong, the test framework apparently reports a truncated 32-bit signed result (my guess) instead of the expected 64-bit unsigned result for the failed test.

Range: 0 to 100000000

There's a fixed test with n = 101101291, and the random tests seem to take it even further.

That gets rid of the ambiguity, thanks! However, I must say that changing the percentage at the end of the month and then calculating with it for that month is borderline criminal. But perhaps expected when bankers and car salsemen are involved.

The honest thing to do is to change the percentage at the start of the month and calculate with it at the end of the month. But maybe that's just me...

It is impossible to know if the bi-monthly loss increase should first be applied at the end of the first or second month. It is thus impossible to get the kata right without luck or trial and error.

Please fix the description.