Use this calculator to count valid selections and ordered arrangements of distinct items when particular items are mandatory or unavailable. The main solver handles k required items that must appear in every result and f forbidden items that are removed before the count is made.
How to use the constrained permutation and combination calculator
This constrained combinatorics calculator answers “how many valid outcomes?” after you decide whether order matters and identify any fixed inclusions or exclusions. A permutation treats different orders as different outcomes; a combination treats the same group as one outcome regardless of listing order. The solver then applies the required-item and forbidden-item rules to that choice.
The calculator can represent committee choices, shortlists, rankings, seat assignments, symbol strings without repetition, and product bundles when the restrictions concern particular distinct items. Its companion tabs cover plain permutations, plain combinations, role-based team selection, and a simplified shift-assignment count, while the constrained form is the page’s central tool.
Enter counts rather than names: the solver needs to know how many particular items are forced into every outcome and how many are excluded. That count-based input is sufficient when all items are distinct and the constraints do not overlap, and it keeps the calculation tied to standard permutation and combination rules.
Permutation or combination for constrained outcomes?
For a constrained counting problem, choose the mode according to whether the positions in the final result are distinct. A permutation counts ordered outcomes: if A-B-C and C-B-A are different, order matters. A combination counts an unordered group: if those listings describe the same group, order does not matter.
Ask whether roles or positions distinguish the chosen items. A race podium has first, second, and third place, so it uses a permutation. A committee of three people has no inherent ranking, so it uses a combination. Password strings and seat assignments are usually ordered; teams and shortlists usually are not.
| Aspect |
Permutation |
Combination |
| Order importance |
Order matters, so ABC and BAC are different. |
Order does not matter, so ABC and BAC are the same selection. |
| Standard formula |
P(n, r) = n! / (n − r)! |
C(n, r) = n! / (r!(n − r)!) |
| Typical use |
Rankings, seating, sequences, codes |
Teams, committees, bundles, subsets |
| Intuition |
Usually larger because each chosen set can appear in many orders. |
Smaller because all orderings of the same set collapse into one result. |
Inputs for required and forbidden items
The constrained solver uses four numerical inputs in addition to the mode. n is the total number of distinct available items. r is the number of items to select or arrange. k is the number of particular items that must occur in every valid result. f is the number of particular items that are forbidden and removed from the pool. Selection is without replacement, so an item cannot be used twice.
In this required-and-forbidden model, “required” means that specified identities are already guaranteed to be in the result, not that at least k items must come from a category. “Forbidden” means specified identities cannot appear. The calculator does not directly handle rules such as “at least two engineers” or “exactly one from each department,” which require a different counting method.
Formula used for constrained nCr and nPr
The solver first excludes forbidden items. From n total items with f forbidden, there are n − f allowed items. The k required items are already part of every valid result, leaving r − k additional items to draw from the (n − f) − k allowed, non-required items.
In combination mode, the solver chooses those additional items without order. In permutation mode, it first chooses the additional items and then counts all orderings of the complete r-item arrangement, including positions occupied by required items.
When k = 0, these reduce to the ordinary nCr or nPr formula using the allowed pool. The count is 0 when the rules cannot be satisfied: for example, when more items are requested than are available, more items are required than the result size, or required and forbidden counts would overlap.
Worked example: required and forbidden items in a 4-item selection
Suppose there are n = 10 distinct items and you need r = 4. Two specified items are required, so k = 2, and one different item is forbidden, so f = 1. Excluding the forbidden item leaves 10 − 1 = 9 allowed items. Since the two required items are already included, choose 4 − 2 = 2 additional items from 9 − 2 = 7 allowed, non-required items.
In combination mode, the result is C(7, 2) = 21 valid 4-item selections. In permutation mode, each chosen four-item group can occupy the four ordered positions in 4! = 24 ways, so the result is C(7, 2) × 4! = 504 valid arrangements. This difference is why the mode must match whether the positions are meaningful.
How to interpret a constrained counting result
A result from this constrained nCr/nPr calculator is a count, not a probability. It is the number of valid selections or arrangements satisfying the stated required and forbidden item rules. A result of zero means the restrictions cannot all be met at once.
For this solver, adding forbidden items cannot increase the count because it shrinks the available pool. Requiring particular items limits which outcomes qualify, although the numerical effect depends on the selection size and whether order is counted. Switching from combinations to permutations generally increases the count because a single valid group can have multiple distinct orders.
Assumptions behind constrained combinatorics
The required-and-forbidden item solver assumes distinct items, selection without replacement, and simple identity-based restrictions. Those assumptions define the problem the calculator solves; they are as important as the arithmetic used to count it.
This makes the page suitable for a question such as “How many 4-person committees can be formed from 12 people if one particular person must serve and two particular people are unavailable?” It is not designed for “at least one from group A,” “no two adjacent,” or “Alice and Bob cannot both be selected.” Such rules need inclusion-exclusion, cases, recursion, dynamic programming, or enumeration.
Why constrained permutation counts grow quickly
Permutation and combination counts can become large quickly because factorials grow rapidly. The constrained solver may display large values in scientific notation when a full integer would be difficult to read, which helps show the scale of a large search space.
The calculator uses JavaScript numbers, so extremely large counts can exceed safe integer precision. In that range, the display remains an indication of magnitude but may not retain every integer digit exactly. For moderate classroom and planning inputs, the output is generally straightforward to read.
Companion permutation, team, and scheduling tools
The tabs below the main solver provide plain permutation and combination counts, a role-based team calculation, and a simplified scheduling calculation. They are separate tools: changing one does not alter the constrained count above.
The team tab multiplies independent combination counts for the listed roles. The scheduling tab is a simplified assignment model for rough counting rather than a full staff-scheduling system; real schedules can also depend on availability, qualifications, legal limits, and preferences.
Checks for constrained nCr/nPr inputs
When a constrained result is unexpected, first verify the model. A frequent error is choosing combinations when positions actually matter, or treating “required” as a category quota rather than a list of particular items. Similarly, a forbidden count represents particular items removed from the pool, not items that are merely unlikely to be selected.
- Check order: use permutation mode for distinct positions and combination mode for an unordered group.
- Check feasibility: r cannot exceed the number of items remaining after exclusions.
- Check k: required items are particular identities and must fit within r.
- Check f: forbidden items are removed before the count is made.
- Check overlap: an item cannot be both required and forbidden.
- Check distinctness: the formulas assume no item repeats.
For a useful constrained-counting check, change one input at a time. Excluding more items should not raise the count, and an impossible set of restrictions should return zero rather than a negative number. These checks help catch a modeling mistake before the result is used in a decision or explanation.
Problems suited to the constraint solver
This calculator can count shortlists with disqualified applicants, product bundles containing mandatory items, ranked lineups that exclude unavailable participants, and symbol arrangements with banned characters. Each example works when the relevant restrictions are on specified distinct items rather than broad category conditions.
For instance, a 12-applicant shortlist of 5 with one required applicant and two disqualified applicants is a constrained combination problem. An ordered 4-symbol sequence from eight distinct symbols with one banned symbol is a permutation problem. A sports roster divided into fixed positions belongs in the team tab, where the independent role choices are multiplied instead.
Understanding required-item combinatorics in plain language
Constrained combinatorics counts selections and arrangements after rules such as “must include this item” and “cannot use that item” are applied.
In required-and-forbidden item problems, organized counting avoids listing every possible outcome by hand. First identify whether order matters, then remove unavailable items and account for items that must appear. This reduces the original problem to a smaller standard permutation or combination count.
A factorial, written as n!, multiplies all positive integers from 1 up to n. It grows quickly, which is why ordered arrangement counts can become large even with moderate inputs. Permutations and combinations are built from factorials, while the product rule multiplies independent choices made in separate stages.
Consider a podium. If 10 runners compete for 3 ranked places, the count is a permutation because first, second, and third are distinct positions. Choosing 3 pizza toppings from 10 is a combination because naming the toppings in a different order does not change the pizza. The same numerical inputs can therefore produce different answers.
Required and forbidden constraints extend these basics directly. Removing unavailable items reduces the pool. Treating specified required items as already included reduces the number of remaining choices. For ordered results, the required items can still occupy any of the ordered positions, so all orders of each valid full result are counted.
The team selection tab illustrates the product rule. When players are chosen independently by role, count the available choices for each role and multiply them. This differs from the main solver, which starts with one pool and applies required and forbidden identities within that pool.
Counts and probabilities are related but not identical. This page reports how many valid outcomes exist. A probability additionally requires a random process and assumptions about how likely outcomes are. Counts can support a probability calculation only after those assumptions are specified.
More complex restrictions remain combinatorics problems, but rules such as “at least one from group A,” “exactly two from each department,” or “two named people cannot both be selected” often require cases or advanced techniques. The required-and-forbidden model here is a focused foundation for those broader problems.