FACTDOUBLE

What it does

FACTDOUBLE(number)

FACTDOUBLE(number) returns the double factorial: the product of the argument with every second integer below it, down to 2 or to 1. Microsoft's page gives both branches:

n!! = n·(n-2)·(n-4)·…·4·2    for even n
n!! = n·(n-2)·(n-4)·…·3·1    for odd n

The name is misleading and worth clearing up once: n!! is not (n!)!, and it is not 2·n!. It is a product with every other factor removed.

The two branches are genuinely different objects. The even branch is a factorial scaled by a power of two — which in binary64 costs nothing, since scaling by 2^k only shifts the exponent field. The odd branch is a ratio, and it is the one that appears in the coefficients of Legendre polynomials, in the Wallis product, in Bessel-function series and in the volume of the n-sphere. Half of the reason this function exists on a worksheet is the odd branch.

Arguments

Try it

Quirks

Result and edge cases

Returns Number, mathematically always a positive integer.

• FACTDOUBLE(0) and FACTDOUBLE(1) — both 1, by the empty and singleton product conventions. Microsoft's page states the negative rule but does not state these two values explicitly; they follow from the printed product forms read at their boundaries.
• FACTDOUBLE(-1) — a documented divergence from the standard convention. In the mathematical literature (-1)!! = 1, and that convention is not decorative: it is what makes the recurrence n!! = n·(n-2)!! and the gamma relation extend correctly, and it is used in the series expansions the odd branch appears in. Microsoft's page documents negative arguments as #NUM!, which excludes -1. Either Excel refuses a value the literature defines, or the documentation is broader than the implementation. The Handbook has not checked, and this is the first probe below.
• Fractional arguments — truncate. As on FACT, whether the domain check sees the raw or the truncated argument decides the interval (-1, 0), and the documentation does not say.
• Parity is decided after truncation, necessarily, since a fractional argument has no parity. That means FACTDOUBLE(7.9) follows the odd branch.
• Above the exactness boundaries — the result is rounded. Note the boundaries are far apart for the two branches: the even branch stays exact to 44 and the odd branch only to 29. See the numerical notes for why.

Errors

As documented on Microsoft's FACTDOUBLE page:

How to implement

Numerical notes

The two branches deserve different implementations, and the reason is a fact about binary64 rather than about combinatorics.

The even branch is free. (2k)!! = 2^k · k!. Multiplication by a power of two is exact in binary64 — it adjusts the exponent field and touches no significand bit — so the even branch is exactly as accurate as FACT is, and exactly representable for the same k. That is why the exactness boundary sits at n = 44: it is 2 × 22, and 22 is the largest k with k! exactly representable. An implementation that computes the even branch as a product loop throws this away for nothing; computing it as 2^k · FACT(k) inherits FACT's accuracy and the scaling costs no error at all.

The odd branch is not free. (2k+1)!! = (2k+1)!/(2^k k!) is a genuine ratio, and its exactness boundary is much lower — n = 29 — because the odd product accumulates factors with no trailing zero bits at all. Odd numbers are odd; the product of k of them has no factor of two to give it trailing zeros, so it consumes significand bits at full rate. This asymmetry is the single most useful implementation fact on this page and it is invisible from the documentation.

The domain is small enough to tabulate — twice. There are 151 even arguments up to 300 and 150 odd ones up to 299, so 301 correctly rounded doubles cover the entire function. As on FACT, a table is faster than a loop, exact where exactness is possible, and correctly rounded everywhere else. There is no reason to ship anything else.

What a product loop costs. Rounding at every step, accumulating roughly as the square root of the number of factors in the best case. For the odd branch at n = 299 that is 150 multiplications, and a few ulp of drift by the end is unremarkable. Ascending and descending loops give different answers, which is the same op-graph question COMBIN's evidence turns on — and unlike COMBIN, here the correct answer is known independently, so the question is decidable without an oracle for every argument.

For consumers: the double factorial is almost always wanted inside a ratio — a Legendre coefficient, a Bessel term, a sphere volume — and the ratio is better computed by its own recurrence than by dividing two FACTDOUBLE results. (2k+1)!!/(2k)!! stays around √(2k/π) for all k, while both halves overflow past 300.

Rust code

33 factdouble "FACTDOUBLE" (1, 1) [V "number"] |s, a, sv| {
    reject_logical(&a[0])?;
    unary(s, a, k::factdouble::factdouble_kernel)
}

pub fn factdouble_kernel(n: f64) -> Result<f64, WorksheetErrorCode> {
    let truncated = trunc_nonnegative_or_minus_one(n)?;
    ExcelRealPolicy::FINITE
        .publish(n, double_factorial_of_int(truncated))
}

pub fn trunc_nonnegative_or_minus_one(n: f64) -> Result<i64, WorksheetErrorCode> {
    if n < -1.0 {
        return Err(WorksheetErrorCode::Num);
    }
    Ok(n.trunc() as i64)
}

pub fn double_factorial_of_int(n: i64) -> f64 {
    // Live Excel 16.0 b20326: FACTDOUBLE is the reverse native odd/even
    // product n*(n-2)*... (not the forward fold). Forward diverges by n=50.
    if n <= 1 {
        return 1.0;
    }
    let mut acc = 1.0;
    let mut k = n;
    while k >= 2 {
        acc *= k as f64;
        k -= 2;
    }
    acc
}

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-FACTDOUBLE-001: 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.

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

Recorded environments and comparison details.

Alternatives

Relationships

• FACT — joined by n! = n!! · (n-1)!!, a free cross-surface identity that neither page's evidence covers and that requires no oracle to test.
• GAMMA, GAMMALN — the odd branch is a half-integer gamma value: (2k-1)!! = 2^k Γ(k+½)/√π. Excel exposes GAMMA, so FACTDOUBLE(2k-1) and 2^k · GAMMA(k+0.5) / SQRT(PI()) are two routes to one number, across two surfaces with different substrates. That is a strong probe and it is unused.
• SQRTPI — appears in the same identity, and exists on the worksheet surface precisely because √π shows up wherever half-integer gammas do.
• COMBIN, MULTINOMIAL — the other combinatorial surfaces with factorial overflow hazards. The central binomial coefficient is C(2k, k) = 2^k · (2k-1)!! / k!, another cross-surface bridge.
• BESSELJ, BESSELY, BESSELI, BESSELK — their series coefficients are double factorials; the odd branch is where it appears.
• SERIESSUM — the natural consumer, for the same reason.

Named variants

No named variants are recorded yet.