POWER

What it does

POWER(number, power)

POWER(number, power) returns number raised to power — written x^y below.

The mathematics is not one function but a family of cases, and every implementation difficulty on this page comes from the seams between them.

For x > 0, all real y:

x^y = exp(y · ln x)

This is the definition, not merely an evaluation strategy (A&S 4.2.1). It is smooth in both arguments and is the only case with no discussion.

For x = 0:

0^y = 0        for y > 0
0^y            undefined (a pole) for y < 0
0^0            indeterminate

0^0 is the famous one. Combinatorics and the binomial theorem want 1; the limit of x^y along the path y = 1/ln x is e; the limit along x = 0 is 0. The two-variable limit does not exist, so the value is a convention, and different systems choose differently. IEEE 754 and C99 pow both specify pow(0,0) = 1. Excel does not — see below, and note that this is one of the very few places where a spreadsheet knowingly departs from the floating-point standard.

For x < 0: x^y has no real value for general real y. It has a real value exactly when y is an integer, and — by the odd-root convention — when y = p/q in lowest terms with q odd, in which case x^y = −(|x|^y). Off those points the principal complex value exp(y·(ln|x| + iπ)) is not real, and the principal branch of the complex logarithm has its cut along the negative real axis, which is precisely where the base lives. So the negative-base case is not a bug to be worked around; it is a branch-cut question that every implementation has to answer explicitly.

Range. For x > 0 the result is positive; for x < 0 and admissible y the result carries the sign of (−1)^y. Overflow and underflow arrive fast: x^y exceeds binary64 range as soon as y·log₁₀|x| > 308.25.

Arguments

Both are numeric slots under ordinary to-number coercion — see Coercion and lifting. Text that reads as a number converts; logicals convert to 1 and 0; an error in either slot propagates.

Try it

Quirks

Result and edge cases

Returns Number.

precision_rounding_profile: integer_exponent_publication

Boundary cases, each with its source named:

• POWER(0, negative) — the same stream records =0^-1 → #DIV/0!. The pole is reported as a division error rather than a domain error, which is the reading that treats x^-n as 1/x^n.

Errors

Microsoft's documentation states none of these rows. The VBA reference lists no error condition for Power at all. Every row above is either shared-model machinery or an upstream live-Excel observation, and the Handbook has not re-observed any of it.

How to implement

Numerical notes

pow is the hardest of the elementary functions to get right, and the reasons are worth stating because they explain every deviation above.

Error amplification through the logarithm. Writing x^y = exp(y ln x), a relative error ε in ln x becomes a relative error of about |y ln x| · ε in the result. Since |y ln x| can reach 709 before the result overflows, a logarithm accurate to one unit in the last place buys a result accurate only to about 2⁹·ulp. Every serious implementation therefore computes ln x in extra precision — Cody & Waite use a split representation, fdlibm's __ieee754_pow carries about 2⁻⁵³ of extra headroom in a two-word product, and correctly rounded libraries (CRlibm, MPFR) go further. This is the single fact that explains why "just call exp and ln" is not an implementation.

Negative bases are a branch decision. The odd-root convention is not a mathematical necessity; it is a choice to prefer the real branch over the principal complex one. Once made, it raises the question of when an exponent counts as a reciprocal odd integer — and the upstream record here is instructive: the acceptance band was found to be decimal-shaped, widening by a factor of 100 around 1/101 relative to 1/3, which is the signature of a test performed on the decimal rendering of 1/y rather than on its bits.

Host-CPU sensitivity. EV-MATH-0002's reader warning records that the 0.5 → sqrt and integer paths are CPU-independent while the general fractional path is not, and carries the same x87 microcode caveat as EXP and LN. A power result is therefore not necessarily portable across machines even within one Excel build — which is exactly the distinction the Handbook's portable-reproducible flavour exists to name; see About implementation options.

Rust code

31 power "POWER" (2, 2) [V "number", V "power"] |s, a, sv| {
    let x = num(s, a, 0)?;
    let y = num(s, a, 1)?;
    super::arithmetic::power_value(s, x, y)
}

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-POWER-001: build 19929 versus build 20430; 27 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

• EXP and LN — the pair the fractional path is built from. POWER(x,y) and EXP(y*LN(x)) are different computations even when both are defined.
• SQRT — for y = 0.5 a hardware square root is correctly rounded and a general power is not, which is why SQRT(x) and POWER(x, 0.5) are worth distinguishing. EV-MATH-0002 records that the exponent-½-is-sqrt behaviour was discovered during the upstream sweep rather than assumed.
• Confused with EXP. EXP(x) is e^x, not x^e. The mistake is common enough that it is worth the sentence.

Named variants

No named variants are recorded yet.