COMBIN

What it does

COMBIN(number, number_chosen)

COMBIN(number, number_chosen) is the binomial coefficient. Writing n for number and k for number_chosen, Microsoft's page states the defining formula directly:

C(n, k) = n! / ( k! (n-k)! )

It counts the subsets of size k of a set of size n — sets, so internal order does not matter. Microsoft's page draws exactly that contrast: combinations are distinct from permutations, "for which the internal order is significant".

The properties that matter for reading and for implementing:

Two consequences shape everything downstream. First, the true value is always an integer, so any returned value with a fractional part is evidence about the evaluation route rather than about the mathematics. Second, the values grow fast: the central coefficient C(n, ⌊n/2⌋) is asymptotically 2^n / √(πn/2), so it passes 2^53 — the last integer beyond which binary64 cannot represent every integer — in the high fifties, and passes the largest finite double somewhat past n = 1000. Every interesting question about this function lives above the first threshold and below the second.

Arguments

Try it

Quirks

Result and edge cases

Returns Number, mathematically always a positive integer.

• k = 0 or k = n — the value is 1, including the vacuous C(0, 0) = 1.
• Non-integer arguments — documented to truncate toward zero before the count is formed.
• Results above 2^53 — the exact combinatorial answer is no longer representable as a binary64 integer, so some rounding is unavoidable in any implementation. What is not unavoidable is which representable neighbour you land on, and that is the whole content of the evidence attached to this page.
• Results above the largest finite double — the mathematics overflows. The reference engine's real-result policy for this surface records non_finite=allow, meaning a non-finite result would be published rather than converted to an error. That is a divergence worth naming: EV-MATH-0008 records the "Excel never publishes an infinity" convention for a named list of surfaces, and COMBIN is not on that list. Nobody has checked what Excel returns when the binomial coefficient overflows.

Logicals, text-that-looks-numeric, blanks and error arguments follow the shared call model; the mechanically rendered battery beside this page shows the boundary probes for those kinds.

Errors

As documented on Microsoft's COMBIN page:

How to implement

Numerical notes

The naive route — form n!, k! and (n-k)!, then divide — is the formula Microsoft prints and the algorithm nobody should ship. It overflows at n = 171 even when the answer is tiny (C(200, 1) is 200), and it throws away exactness long before that.

The standard remedies, in the order a careful implementation applies them:

1. Reduce by symmetry: replace k with min(k, n-k). This halves the worst-case work and, more importantly, shortens the product that accumulates rounding. EV-MATH-0016 records this reduction as a confirmed structural finding about Excel — one of the few things about this surface that is settled.
2. Use the multiplicative recurrence with the division inside the loop: acc ← acc · (n-k+i) / i for i = 1 … k. Each partial product is itself a binomial coefficient, hence an exact integer while it fits, so the intermediate never overflows earlier than the result does. The alternative "multiply everything, divide once" ordering overflows spuriously.
3. Return exact integers where they fit. Below 2^53 the answer is representable and an integer-arithmetic path can return it exactly.
4. Above 2^53, choose and document a rounding discipline. This is where implementations diverge, and it is where the evidence sits.

The evidence attached to this page — EV-MATH-0016 and EV-MISC-0015 — records a capture built specifically to discriminate between candidate op-graphs, and its result is negative in an unusually informative way. An earlier claim that this surface agreed with Excel below 2^53 was withdrawn, because it rested on a corpus that could not tell the candidates apart. On the discriminating pairs, the ruled-out list covers every product-loop family in both directions, strict and per-step double-rounded and fully extended orderings, factorial-ratio forms, reciprocal-multiply forms, and compositions of the published GAMMALN. Plain-double and x87 extended-precision product orderings score identically. The record states plainly that the op-graph is unidentified, that a subset of the discriminating rows is matched by no candidate form at all, and that Excel sits below the multiply-first product at larger n and k. The figures belong to the evidence layer and render beside this page; the shape of the finding is the part that belongs in prose.

The literature context: A&S chapter 24 gives the identity set; Knuth volume 1 §1.2.6 is the standard source for the symmetry-and-multiplicative-recurrence discipline; Numerical Recipes' bico uses the exp(factln) route and states its own accuracy caveat, which is exactly the route ruled out for this surface and identified for its sibling.

Rust code

34 combin "COMBIN" (2, 2) [V "number", V "number_chosen"] |s, a, sv| {
    out(s, k::combin::combin_kernel(num_with_subnormal(s, a, 0)?, num_with_subnormal(s, a, 1)?))
}

No implementation has been published with a Handbook test suite for this function.

Version differences

The recorded environments below distinguish a reading from a same-input comparison. Counts describe captured inputs in each environment; overlapping captures and comparisons are not totals of unique worksheet calls.

• XC-COMBIN-001: build 19929 versus build 20131; 4 same-input pairs, 0 differing answers. Compared axes: excel-build. Numeric answers were compared by their recorded binary64 bits; other answers by typed value.
• XC-COMBIN-002: build 19929 versus build 20228; 103 same-input pairs, 0 differing answers. Compared axes: excel-build. Numeric answers were compared by their recorded binary64 bits; other answers by typed value.
• XC-COMBIN-003: build 19929 versus build 20430; 2 same-input pairs, 0 differing answers. Compared axes: excel-build. Numeric answers were compared by their recorded binary64 bits; other answers by typed value.
• XC-COMBIN-004: build 20131 versus build 20228; 503 same-input pairs, 0 differing answers. Compared axes: excel-build. Numeric answers were compared by their recorded binary64 bits; other answers by typed value.
• XC-COMBIN-005: build 20131 versus build 20228; 503 same-input pairs, 0 differing answers. Compared axes: excel-build. Numeric answers were compared by their recorded binary64 bits; other answers by typed value.
• XC-COMBIN-006: build 20228 versus build 20430; 14 same-input pairs, 0 differing answers. Compared axes: excel-build. Numeric answers were compared by their recorded binary64 bits; other answers by typed value.

Agreement on these compared inputs does not establish agreement on unmeasured inputs.

Recorded environments and comparison details.

Alternatives

Relationships

• COMBINA — the with-repetition sibling, COMBINA(n, k) = C(n+k-1, k). The two are joined by that single identity and separated by very different evidence: see the numerical notes on both pages.
• PERMUT — the ordered count, P(n, k) = n! / (n-k)!, related by P(n, k) = C(n, k) · k!. PERMUTATIONA is its with-repetition partner, n^k.
• FACT — the factorial the documented formula is written in. Evaluating COMBIN as that formula is the one implementation choice you should not make; see below.
• GAMMALN, GAMMALN.PRECISE — the log-gamma route, C(n,k) = exp(lnΓ(n+1) − lnΓ(k+1) − lnΓ(n-k+1)), which is how many libraries evaluate large binomials and which is identified as the substrate for COMBINA but not for COMBIN.
• HYPGEOM.DIST, BINOM.DIST — the distribution functions whose mass functions are binomial coefficients times probabilities; they usually need better than a COMBIN product.

Named variants

No named variants are recorded yet.