SQRTPI

What it does

SQRTPI(number)

SQRTPI(number) returns

sqrt(number * pi)

• Domain: [0, +infinity). Microsoft's page states: "If number < 0, SQRTPI returns the #NUM! error value."
• Range: [0, +infinity), with SQRTPI(0) = 0 and SQRTPI(1) = sqrt(pi).
• Shape: a scaling of SQRT by sqrt(pi), so it inherits every structural property of the square root — strictly increasing, concave, principal branch, relative condition number exactly 1/2, branch point at the origin.

Why the constant is pi and not something else. sqrt(pi) is not an arbitrary convenience. It is Gamma(1/2) (A&S 6.1.8), and it is the normalizing constant of the Gaussian: the error function is defined as erf(x) = (2/sqrt(pi)) * integral from 0 to x of e^(-t^2) dt (A&S 7.1.1), and the normal density carries 1/sqrt(2 pi). Expressions of the form sqrt(2 pi sigma^2) and sqrt(n pi) (Stirling's approximation: n! ~ sqrt(2 pi n) (n/e)^n) occur constantly in statistics and in asymptotic analysis. SQRTPI exists so that a worksheet can write one call instead of SQRT(n * PI()).

That is the whole of the mathematics. The function is a composition of a multiplication and a square root, and everything interesting about it is which square root.

Arguments

The commonly misunderstood position: number is the argument of the multiplication, not of the root. SQRTPI(2) is sqrt(2 pi), not 2 sqrt(pi). Readers who want 2 sqrt(pi) want SQRTPI(4).

Try it

Quirks

Result and edge cases

Returns Number.

• Zero gives zero.
• Negative gives #NUM!, as documented.
• Very large arguments. This is where the function stops being boring. number * pi overflows binary64 for arguments above roughly the top of the range divided by pi, and the overflow happens in the intermediate product, before the root is taken — even though sqrt(number * pi) would be an entirely ordinary number if computed with any headroom. A two-step implementation therefore has a band of arguments it cannot answer that the mathematical function has no trouble with. The remedy is standard and cheap: scale by a power of four before the multiplication and by the corresponding power of two after the root. Whether Excel does this is unverified.

1. The documented #NUM! for negative arguments is not expressed by the declared axis. arg_domain_guard=none says there is no argument-domain guard; Microsoft documents one. The likely reading is that the check lives inside the Custom kernel rather than in the axis vocabulary, making this a classification gap rather than a behavioural claim — but the Handbook records the mismatch, because a reader consulting the axis alone would conclude the function is total on the reals.
2. non_finite=allow would permit publishing an infinity. For an argument large enough that number * pi overflows, a naive two-step evaluation produces an infinite intermediate and an infinite root, and non_finite=allow does not reject it. That sits in tension with the Handbook's evidence record EV-MATH-0008, whose finding — for a different set of surfaces, not including SQRTPI — is that Excel never publishes an infinity and maps non-finite real results to #NUM!. Whether SQRTPI is an exception to that convention, or whether the axis value is simply not load-bearing here, is an open question and the sharpest probe on this page.

Errors

What happens at the overflow boundary is not documented and is not settled by the reference engine's declared axes; see above.

How to implement

Numerical notes

The finding on this surface is about the routine, not the mathematics. Both evidence records attached to this page make the same point from different angles: the square root here is performed by a general power routine — (n*pi)^0.5 — rather than by a dedicated square root.

That distinction is not pedantry. IEEE 754 requires squareRoot to be correctly rounded; it requires nothing of the sort from pow. A correctly rounded sqrt returns the true value rounded once; a general pow typically computes exp(0.5 * log(x)) with extended-precision bookkeeping and lands on the correctly rounded value almost always, but not always. The two therefore agree at ordinary magnitudes and can part company near the extremes of the exponent range. EV-MISC-0014 records the witness: at the input where n*pi reaches the largest finite double, the correctly rounded square root and the power routine give different results, and the record's reading is that the power routine is the less accurate party while the reference engine reproduces it deliberately. EV-MISC-0014 also rules out x87 extended precision as the cause — both sides of that comparison are SSE2 — so this is a routine-choice effect, not a register-width effect.

Both records carry a reader warning about attribution, and the warning is the interesting part of the epistemology: the count that exists in the upstream source has a power routine as its grammatical subject, not SQRTPI worksheet calls, and neither record is willing to republish it as a pass rate for this function. This page states none of those figures; the evidence layer renders them beside it with their warnings attached.

What a careful implementation does. Three things, in order of importance:

1. Use sqrt, not pow, if the goal is the mathematically best answer. This costs nothing and buys correct rounding of the root. It is also, per the records above, precisely the choice that would disagree with Excel at the extremes — which is the four-flavour distinction this Handbook exists to make explicit: an Excel-compatibility implementation and a mathematically-correct implementation genuinely differ here, and both are right about different questions.
2. Guard the intermediate. n * pi is one multiplication and one rounding; the product both overflows for large n and loses a rounding step that the true sqrt(n*pi) does not have. Scaling n down by a power of four and the result up by the matching power of two removes the overflow band exactly, because powers of four are exact under square root.
3. Consider the two roundings. Even ignoring pow, SQRTPI rounds twice — once forming n*pi, once taking the root. A correctly rounded SQRTPI would need the product in higher precision (a two-product/fma split is enough) before rooting. No implementation is obliged to do this, and the Handbook is not claiming any does; it is the difference between "the square root of the rounded product" and "the rounded square root of the product", and those are different functions in the last bit.

Rust code

30 sqrtpi "SQRTPI" (1, 1) [V "number"] |s, a, sv| {
    reject_logical(&a[0])?;
    unary(s, a, k::sqrtpi::sqrtpi_kernel)
}

pub fn sqrtpi_kernel(n: f64) -> Result<f64, WorksheetErrorCode> {
    if n < 0.0 {
        return Err(WorksheetErrorCode::Num);
    }
    // Excel computes SQRTPI(n) = `(n·π)^0.5` via its `pow` routine — NOT the IEEE
    // correctly-rounded `sqrt` — and publishes `#NUM!` once the `n·π` intermediate overflows
    // f64. Reproduce BOTH: form the same `n*π` product, reject (`#NUM!`) when it is non-finite
    // (the overflow flips at exactly Excel's input, n > f64::MAX/π ≈ 5.7222122209853366e307,
    // 0x7fd45f306dc9c882↔0x7fd45f306dc9c883), and take the MSVC runtime's `pow(·, 0.5)` rather
    // than `sqrt`. That `pow` matches Excel bit-exactly across the whole range INCLUDING the
    // scattered 1-ULP points where correctly-rounded `sqrt` differs from it — e.g. the
    // n*π==f64::MAX input 0x7fd45f306dc9c882: `sqrt`→0x5fefffffffffffff, but Excel and `pow`
    // both →0x5ff0000000000000. (This is `pow` vs `sqrt`, not x87/extended precision.)
    // Verified live Excel 16.0 build 20026 (.tmp/sqrtpi-broad-oracle.ps1 + sqrtpi-boundary-
    // oracle.ps1): 30/30 sampled inputs, the runtime's `pow` == Excel; `sqrt` missed the 2
    // near-overflow points. Resolves oxf-quxx. [`crt_pow`] is that `pow` on every target (dc-sbo).
    let product = n * std::f64::consts::PI;
    if !product.is_finite() {
        return Err(WorksheetErrorCode::Num);
    }
    Ok(crt_pow(product, 0.5))
}

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-SQRTPI-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

• SQRT — the underlying operation, and the function SQRTPI is not implemented on top of, according to the evidence attached to this page. That is the whole story of this surface.
• PI — the constant. SQRTPI(n) and SQRT(n * PI()) are the same mathematical value and are not guaranteed to be the same double, because they take different routes.
• POWER and the ^ operator — the general power routine, which is what the evidence records identify as the substrate here.
• GAMMA — SQRTPI(1) is GAMMA(0.5), exactly. That identity is a free cross-check between two unrelated implementations in the same workbook.
• NORM.DIST, NORM.S.DIST, ERF — the consumers. Every one of them carries a sqrt(pi)-family constant internally, which is why this function exists.
• Confused with: SQRT(PI() * number) written by hand, which is the same thing and may not produce the same bits; and with PI() alone.

Named variants

No named variants are recorded yet.