Why is counting a build matrix's policy-excluded combinations and subtracting often easier than counting the allowed ones directly?
answer
- count what is removed instead
- total minus banned, exact
- the banned side is smaller
- banned set often a product
- each banned item removed once
basics
~20 sThe excluded side is usually the smaller and simpler one to describe, and it is often a clean product while the allowed side is not. Complementary counting is exact: full universe minus excluded, provided each excluded item is counted once.
solid answer
~50 sComplementary counting says: count everything, count what must be removed, subtract. A matrix of three runtime versions, four operating systems and two architectures holds `3 * 4 * 2 = 24` combinations. If policy bans one particular operating-system-and-architecture pair for every version, the banned set is itself a product — `3 * 1 * 1 = 3` — so the allowed total is `24 - 3 = 21`. Counting the allowed side head-on means case analysis across the axes for no gain. The trick is exact rather than approximate, but it has preconditions: the universe must be well defined, every banned combination must actually lie inside it, and each must be counted exactly once. The moment two ban rules can hit the same combination, the plain subtraction double-subtracts, and reconciling that overlap is the inclusion-exclusion principle's job, not this one.
go deeper
Know the move: when a rule says everything except some cases, count the total and the exceptions and subtract. The answer is exact, not an approximation.
Explain why the excluded side is usually easier to describe, and state the preconditions: correct universe, exclusions inside it, each removed once. Show the direct count agreeing with the complement on a small matrix.
Spot the case where two exclusion rules overlap and the naive subtraction removes a combination twice, and say which principle handles it. Keep the count tied to the policy document so a reviewer can follow it.
Decide how the policy is written in the first place: exclusions that are disjoint by construction keep the count auditable, while overlapping ad-hoc rules make the real matrix size an open question.
## What complementary counting is Complementary counting answers *how many satisfy the condition* by answering *how many fail it* and subtracting from the total: `|allowed| = |universe| - |excluded|` That is not a heuristic or an estimate. It is an exact identity whenever the universe is a well-defined finite set and the excluded set sits inside it. Its value is entirely practical: one of the two sides is usually far easier to describe, and it is very often the excluded one. ## Why the excluded side is usually easier A policy exclusion is written as a rule, and a rule is a short description. 'This operating system is unsupported on that architecture' is one sentence that picks out a clean sub-block of the matrix. The allowed set, by contrast, is 'everything except that', which has no short description at all — it is a shape with a bite taken out of it. - The excluded set is frequently **itself a product**: fix some axes, leave the rest free, multiply. - The excluded set is usually **much smaller**, so it is enumerable by hand as a sanity check. - Exclusions are **stated in the policy**, so counting them keeps the count close to the document a reviewer will read. - Direct counting of the allowed side forces **case analysis** over the axes that the exclusion touches, which is more work and more places to slip. ## A worked matrix Three runtime versions, four operating systems, two architectures, every combination in principle available: 1. **Count the universe.** The axes are independent, so the product rule gives `3 * 4 * 2 = 24` combinations. 2. **Count the excluded set.** Policy bans one specific operating-system-and-architecture pair, for every version. Fix those two axes and leave the version free: `3 * 1 * 1 = 3` banned combinations. 3. **Subtract.** `24 - 3 = 21` combinations run. The direct route would have been: for the banned operating system, only one architecture survives, giving `3 * 1 * 1 = 3`; for the other three operating systems, both architectures survive, giving `3 * 3 * 2 = 18`; total `3 + 18 = 21`. The same answer, twice the work, and two chances to misclassify a case. Note that both routes agree — that agreement is itself a good check to run when the numbers are small enough. | | Direct count | Complementary count | |---|---|---| | What you enumerate | the allowed combinations | the universe, then the banned ones | | Best when | the allowed side has clean structure | the banned side is small or is itself a product | | Work above | 3 + 18, split into two cases | 24 - 3, no case split | | Main risk | forgetting a case entirely | subtracting something twice or subtracting something outside the universe | ## The preconditions, in the order they fail 1. **The universe must be counted correctly first.** A complement of a wrong total is a wrong answer, and subtracting a right number from a wrong one looks respectable. 2. **Every excluded item must lie inside that universe.** A ban naming an architecture the matrix never offered removes nothing, and subtracting it produces a count that is too low. 3. **Each excluded item must be counted exactly once.** Two ban rules that can both match the same combination make the naive sum of their counts too large, so the subtraction takes away too much. The third precondition is where this technique meets its limit. When exclusion rules overlap and you cannot redefine them into disjoint families, the correction that adds shared combinations back is the **inclusion-exclusion principle**, which generalises to any number of overlapping sets with its own alternating-sign structure. Complementary counting is the one-set case where no such correction is needed, and it is worth being explicit about which of the two you are doing. ## When complementary counting is the wrong move - When the **banned side is the bigger, messier side** — if policy allows only a handful of blessed combinations, count those directly and ignore the complement. - When the **universe is not a clean product**, because then step 1 is as hard as the problem you were avoiding. - When the exclusions are **not stated over the same universe** — for example, a rule about job families rather than matrix combinations. Those are different objects, and subtracting one from a count of the other is a category error rather than an arithmetic one. The habit worth building: whenever a count has the word *except* in it, price both sides before choosing. Ask how many combinations exist in total, how many the policy removes, and whether any combination is removed twice. If the answer to the last question is yes, you are no longer doing complementary counting.
- What must be true of the excluded set for the subtraction to be exact?Three things: the universe was counted correctly, every excluded combination actually lies inside that universe, and each is counted exactly once. Violate the last and the subtraction removes too much; violate the second and it removes combinations that were never there.
- When is complementary counting the wrong tool?When the excluded side is the larger or messier one — if only a few combinations are blessed, count those directly. It is also wrong when the universe is not itself easy to count, since the first step then costs as much as the problem you were avoiding.
saying these in an interview costs you the question
- Calls the complement an estimate rather than an exact count
- Subtracts two ban rules separately when they share a combination
- Subtracts combinations that were never in the counted universe
- Uses the complement even when the excluded side is larger
- Subtracts a count of job families from a count of combinations