Post History

## Optimizing specifically for the given test cases

Applies to "code-speeding" or fastest-code where your program must run as quickly as possible, as well as compression challenges. Obviously, there is a finite amount of cases because we have to measure speed/compression somehow.

It's not in the spirit of the challenge if you optimize your program to work extremely quickly for some cases (E.g. hardcoding the test cases and mapping them to ASCII characters to compress them in one byte), but the program works much worse for other input.

As there is no way around test cases, the general conduct should be that an algorithm's performance on the test cases is representative of its performance on other cases.

Rule of thumb: if you make your algorithm do well on the *majority* of cases and the test cases happen to be in the majority, that's fine, but not if your algorithm does well on a *minority* of cases which happens to cover the test cases given.