Last year I was arranging weekend duty for the department, and the question was "choose 4 out of 12". I got 495; Lao Zhou at the next desk got 11,880. We slapped our drafts on the table and checked each other all afternoon before realizing we were not answering the same question at all: I was asking which four people, he was asking which four people cover which posts.
Since then I have run into the same argument several times: lottery coverage, match line-ups, four-digit locks. After enough of these, I set myself a dumb but useful test, and I have worked through every number below one by one.
Whether order counts: my swap test
Write one result down as it is, swap the positions of two members, and ask a single question: is this still a new outcome? If yes, order counts and you use permutations; if no, use combinations. It sounds trivial, but once you turn it into an action, most problems stop being ambiguous.
| Scenario | After swapping two positions | Which one | Count |
|---|---|---|---|
| 4 chosen from 12, deciding only who is on duty | Still the same four people; the list has not changed | Combination | C(12,4)=495 |
| 4 chosen from 12, each covering one of 4 different posts | Shifts no longer match people; the roster changes | Permutation | A(12,4)=11880 |
| 5 cards dealt from 52, looking only at which five you hold | Still those five; a different order is not new | Combination | C(52,5)=2598960 |
| 4-digit lock, digits cannot repeat | 1234 and 4321 are two different locks | Permutation | A(10,4)=5040 |
| 4-digit lock, digits may repeat | Each position independent, 10 options each | Neither | 10×10×10×10=10000 |
The last row is the second question I now always ask first: can items repeat? Both formulas assume no repetition; once repetition is allowed you are using neither A nor C, but multiplying independent choices per position.
The two formulas differ by a single r!
The number of permutations is A(n,r) = n! / (n-r)! and the number of combinations is C(n,r) = n! / (r!(n-r)!); the only difference is that extra r! in the denominator, so A(n,r) = C(n,r) × r!. That gives a ready-made check: divide the two numbers and the answer should be exactly r factorial. If it does not divide evenly, you have misread the question.
A few pairs I have checked:
- n=12, r=4: C=495, A=11880, ratio 24, exactly 4!
- n=9, r=4: C=126, A=3024, ratio 24
- n=7, r=3: C=35, A=210, ratio 6, exactly 3!
- n=10, r=3: C=120, A=720, ratio 6
- n=6, r=2: C=15, A=30, ratio 2
Combinations have two more hand-calculation checks. Symmetry: C(n,r)=C(n,n-r), so C(10,3) and C(10,7) are both 120, which means you should compute with the smaller r and halve the multiplication steps. Pascal's recurrence: C(n,r)=C(n-1,r-1)+C(n-1,r), so C(8,3)=C(7,2)+C(7,3)=21+35=56. When I need every arrangement listed, I do not type them out myself; I hand it to the Permutation Calculator, which shows the formula and the steps.
The three kinds I actually got wrong
The first is forgetting to ask about repetition. The same four-digit lock has three readings and three numbers: digits may repeat gives 10×10×10×10=10000; no repetition with order counting gives A(10,4)=10×9×8×7=5040; no repetition and only which four digits were used, order ignored, gives C(10,4)=5040/(4×3×2×1)=210. I have been burned when a problem says only "four digits".
The second is "at least". Choose 3 people from 5 men and 7 women, with at least 1 woman required. I started by fixing one woman and then filling 2 more at random: C(7,1)×C(11,2)=7×55=385, and handed that in. The correct method subtracts the complement from the whole: C(12,3)-C(5,3)=220-10=210. The extra 175 is not a typo: groups with two women get counted twice and groups with three women get counted three times. Split by the number of women and you get 70+105+35=210; my method gave 1×70+2×105+3×35=385. This kind of double counting never raises an error; you only see it by counting a different way.
The third is the denominator of a probability. The denominator must be the number of combinations for the complete game, not for one step of it: red balls 6/33 plus a blue ball 1/16 gives C(33,6)×16=1107568×16=17721088, and counting only the red balls misses a factor of 16; the two-zone format gives C(35,5)×C(12,2)=324632×66=21425712. For a sense of scale: five cards with suits distinguished gives 2,598,960 combinations, one drawn per day at 365 days a year takes 7,120.4 years; treating the four suits as equivalent and counting only hand types gives 7,462.
Why the numbers explode so fast
Both formulas run on factorials, and factorial growth is unreasonable. Here is the comparison I worked out:
| Factorial | Value | Still within 2^53-1 |
|---|---|---|
| 15! | 1307674368000 | Yes |
| 18! | 6402373705728000 | Yes |
| 19! | 121645100408832000 | Over the line |
| 20! | 2432902008176640000 | Over the line |
The 2^53-1 here is 9007199254740991, the exact-integer limit of an ordinary number type. But crossing the line does not mean immediate distortion: I compared every factorial from 1! to 25! digit by digit against the double value, and 15! through 22! are identical to double. The first real loss is 23!: the exact value is 25852016738884976640000 and double gives 25852016738884978212864. They cross the line without losing digits because trailing factors of 2 are plentiful and the significant bits still fit in 53, which happens to work but cannot be relied on. The criterion is still 2^53-1: 9007199254740993 is stored as 9007199254740992. So for C(20,10)=184756, double computing 20!/(10!×10!) still returns 184756 with no distortion. I used to insist that the intermediate step was already wrong; my error was taking "the result looks normal" for "the intermediate value is exact". Once the intermediate goes to 23! or beyond, the quotient goes wrong with it. C(100,50) is a 30-digit number, 100891344545564193334812497256, which a fixed-width integer cannot hold, so problems like this need big-number support: the Combination Calculator says it computes large combinations with BigInt, and the Factorial Calculator says it handles 0 to 1000 without overflow.
One more distinction I keep clear: wanting a single number and wanting the full listing are two different scales. The latter grows with the factorial: all permutations of 8 elements is 40,320 rows, 10 elements is 3,628,800 rows, and what collapses first is the page, not the arithmetic. The ceiling is set by the implementation, not by mathematics.
Q: Is A(n,r) always larger than C(n,r)?
Larger or equal, never smaller, because A = C × r!. At r=1 both equal n, and at r=0 both equal 1; those are the two boundaries that confirm the formula is not inverted.
Q: Choosing 3 of 7 people for a meeting versus choosing 3 people for three different roles: how big is the difference?
35 and 210, a factor of 6, which is 3!. If the same three people in a different assignment count as a new plan, that factor of 6 has to be multiplied in.
Q: What if the numbers get too big to compute?
First ask whether you need an exact value. Comparing magnitudes only needs an approximation; if you need it exact to the last digit, do not force it through an ordinary number type. Switch to something that supports big numbers, or simplify the formula before multiplying.
Q: How do I self-check before handing in an answer?
I always check three things: does A divided by C equal r! exactly; did I wrongly use A or C on a problem that allows repetition; did I convert "at least" into whole minus complement. Only when all three pass do I hand it in.
Back to that duty roster. What we used in the end was 11,880 under the by-post reading: each person maps to one shift, and swapping positions makes a new roster. If the discussion had been "just throw people together randomly", the number would be 495. Who was right does not matter; what matters is saying up front whether a swap produces a new outcome.