Chapter 2 of Street Fighting Mathematics is called Easy Cases. The idea is very simple:

A correct solution works in all cases, including the easy ones.

Solution 2 in this writeup of the napkin ring problem is a fun example of applying this principle.

Easy cases can be exploited for software testing as well as in mathematics. Many instances of this are trivial in the sense that any test case written by a human is likely to be an easy case when compared to the universe of all possible inputs. What I’m interested in here are clever and non-obvious applications of easy cases.

Let’s take the example of an FIR filter. Since these eat up a lot of CPU cycles in some systems, people create fiendishly optimized FIRs in assembly that are not so easy to verify by inspection. Chapter 8 of the ARM System Developer’s Guide has many great examples (code here). An FIR filter implementation can be tested using the following easy cases:

• Feed the filter an impulse signal (…,0,0,0,1,0,0,0,…) and it should output its coefficients in order.
• Feed the filter a step signal (…,0,0,0,1,1,1,…) and its output should settle to the sum of its coefficients.
• Feed the filter a sine wave and its output should be a sine wave with the expected amplitude given the filter’s design.

Can you write an FIR that is wrong, but that passes these tests? Sure, but these will weed out a lot of wrong implementations. I learned about these tests here. In general, a lot of codes, particularly mathy ones, have these easy cases that can and should be exploited for simple sanity checks.