Permutation Calculator

Imagine you have a row of empty chairs and a group of people to seat. The first chair has n candidates. Once someone sits, the next chair has n - 1 candidates. The one after that has n - 2. You multiply those options together until you have filled r chairs. That product is the permutation count.

The formula P(n, r) = n! / (n - r)! captures this exactly. The numerator n! represents filling every chair, and dividing by (n - r)! cancels out the chairs you never actually fill. In practice, computing the product directly — n x (n-1) x ... x (n-r+1) — is faster and avoids computing enormous factorials that mostly cancel.

The key distinction from combinations is that sequence is part of the identity of each arrangement. In a podium scenario, runner A finishing 1st and runner B finishing 2nd is a different outcome from runner B finishing 1st and runner A finishing 2nd, even though the same two people are involved. Every swap that changes position creates a brand-new permutation.

Use this calculator when you need to count ordered arrangements and each item can appear at most once. Common cases include assigning ranked positions (1st through 3rd from a group), scheduling ordered sequences (which task runs first, second, third), generating distinct codes or passwords from a set of unique characters, and planning bracket or elimination rounds where seeding order matters.

This tool is also useful as a quick sanity check in probability problems. If you need to find the probability of a specific ordered outcome, the denominator is often a permutation count — the total number of equally likely ordered arrangements.

Do not use this calculator when repetition is allowed (use n^r instead), when order does not matter (use combinations), when the items are not all distinct (use the multinomial coefficient n! / (k1! x k2! x ...)), or when you are working with circular arrangements where rotation produces the same configuration (the formula shifts to (n-1)!).

Mistake 1: Using combinations when order matters. The cause is intuition — people think of selection as a group activity. The consequence is dramatically undercounting arrangements. P(8, 3) = 336, but C(8, 3) = 56. If you are counting ordered assignments and use the combination formula, your answer is off by a factor of 6 (which is 3!).

Mistake 2: Confusing n and r. A common data-entry error is entering the number of selected items as n and the pool size as r. P(3, 10) is undefined — r cannot exceed n. Always confirm: n is the larger pool, r is how many you are pulling from it.

Mistake 3: Applying permutations when items repeat. The standard P(n, r) formula assumes all items are distinct and no item is reused. If you are counting 4-digit PINs where digits can repeat (like 1-1-3-7), the correct count is 10^4 = 10,000, not P(10, 4) = 5,040. Repetition-allowed arrangements use a different formula: n^r.

The core formula is P(n, r) = n! / (n - r)!, where n! (n factorial) means n x (n-1) x (n-2) x ... x 1. For P(10, 3): 10! / 7! = (10 x 9 x 8 x 7!) / 7! = 10 x 9 x 8 = 720. The 7! cancels completely, which is why you only need to multiply r terms.

Permutations and combinations are related by exactly one factor: r! (the number of ways to reorder the r selected items among themselves). C(n, r) = P(n, r) / r!. For P(10, 3) = 720 and r! = 6, C(10, 3) = 120. Every combination corresponds to r! permutations — this ratio is always exact.

Floating-point precision becomes a practical concern above n = 15 or so. Numbers like P(20, 15) exceed one quadrillion. Standard 64-bit floats can represent integers exactly up to 2^53 (about 9 quadrillion), so results remain exact well into the millions and often beyond. Above n = 170, however, the intermediate products overflow to Infinity, which is why this calculator caps n at 170.

The formula P(n, r) = n! / (n - r)! implicitly assumes a flat, uniform pool where every item is equally available. In real scheduling or ranking problems, constraints often invalidate the formula — if person A must precede person B, or certain positions exclude certain candidates, the actual count is lower than P(n, r) and requires inclusion-exclusion or direct enumeration. P(n, r) gives an upper bound in constrained scenarios, not an exact count.

At large n, floating-point multiplication accumulates relative error. For combinatorial cryptography or lottery auditing where exact integer values matter above n = 20 or so, use arbitrary-precision integer arithmetic rather than relying on IEEE 754 double-precision results.