POWER(-8,1/3): Microsoft documents #NUM!, but every engine we run returns the real cube root, about -2

POWER(x,y) raises x to the power y. Microsoft’s rule for a negative base is explicit and restrictive: a negative base with a non-integer exponent is documented as a numeric-domain error, #NUM!, and #NUM! is therefore the expected value recorded in our test corpus for =POWER(-8,1/3). No engine we execute produces it. Google Sheets returns -2, all four LibreOffice builds return -2, and Excel for the web — Microsoft’s own browser build, which we do run — returns -1.9999999999999998. All of those are the real cube root of -8.

The web engine’s -1.9999999999999998 and the exact -2 everywhere else are the same answer to within one unit in the last binary place: the ordinary residue of evaluating a root as exp(y × ln|x|) in double precision instead of special-casing it. That is a rounding difference, not a divergence, and it is the last this page will say about it.

What is left is a gap between what Microsoft documents and what every engine we run actually does — the web build of Excel included — plus a second split on the same function, =POWER(0,0), that runs the other way.

A minimal example

Those are all five POWER cases in our corpus, not a selection. The three controls matter as much as the two that split: an ordinary integer power, a negative exponent and a fractional exponent over a positive base agree exactly in every column, so nothing here is a general disagreement about exponentiation. The divergences are confined to the two edges — a negative base under a fractional exponent, and zero to the zero.

Read each column’s provenance literally, because they are not the same kind of evidence. The Excel, desktop column is documentation, not measurement: #NUM! for a negative base with a non-integer exponent is Microsoft’s stated rule, corroborated by Microsoft’s own community support answer that =(-8)^(2/3) returns #NUM!, and it is recorded as the expected value in our corpus. The Excel for the web column is our dated recalculation run on OneDrive. The Google Sheets column is our dated Drive-import run. The LibreOffice column is what our harness read back after recalculating the workbook in Calc 25.8.7.3, and 24.2.0.3, 24.8.7.2, 25.2.0.3 and 25.8.7.3 all returned identical values, so nothing here is a version difference.

The =POWER(0,0) row needs one caveat stated plainly. The 1 in the desktop column is the corpus expectation — the cross-engine and cross-language consensus value — and not a quoted Microsoft result: Microsoft’s own support answers record the desktop worksheet function returning #NUM! for both =0^0 and =POWER(0,0), reproduced in Excel 2007 and 2010 and reported unresolved, even though VBA’s own x = 0 ^ 0 evaluates to 1 in the same product. So the Excel-web #NUM! we measured is consistent with what Microsoft acknowledges about the desktop product — but we have no desktop run of our own, so treat that as an acknowledged report and not as something we verified. The row that is measured on every side is the one below it: Sheets and LibreOffice return 1, the web build returns an error.

Full executed matrix: POWER.

Why it happens

Odd roots of negative numbers have two defensible answers. Ask for (-8)^(1/3) and there are three complex cube roots of -8. One of them is the real number -2; the principal one, the value the general complex definition exp(y × Log(x)) picks, is 1 + 1.732i, which is not a real number and cannot be put in a cell. An implementation has to choose:

• Refuse the whole class. A negative base with a non-integer exponent has no real principal value in general, so return #NUM! and make the caller be explicit. This is the rule Microsoft documents, and it is simple and predictable: it does not matter whether the exponent happens to be 1/3 or 0.334, the answer is always the error.
• Return the real root when one exists. When the exponent is a fraction with an odd denominator, there is exactly one real answer — here -2 — so hand it back. This is what Google Sheets and LibreOffice do, and what the executed run of Excel for the web did too.

The second option costs something the first does not: it has to decide, in binary floating point, whether an exponent is a fraction with an odd denominator. 1/3 is not exactly representable in a double, so an engine taking this route is really asking whether the reciprocal of the exponent is close enough to an odd integer. That is why the boundary can look arbitrary from outside, and why the answer arrives with a last-bit wobble in one engine and not in another.

Zero to the zero is a convention, not a computation. 0^0 is an indeterminate form as a limit — approach it along x^0 and you get 1, along 0^y and you get 0 — so no amount of arithmetic settles it. Discrete mathematics settles it by fiat instead: the empty product is 1, which keeps the binomial theorem and every polynomial written as a sum of a xⁿ terms working at x = 0. Practically every language agrees; Python, C#, IEEE 754’s pow, VBA and LibreOffice all return 1. Excel is the outlier that treats the indeterminate form as a domain error instead: Microsoft’s support answers record the desktop worksheet function returning #NUM!, and our run of the web build reproduced it.

The two edges therefore fail in opposite directions, which is what makes this function awkward to migrate. At POWER(-8,1/3) the documented error is the strict answer and the engines are permissive; at POWER(0,0) the engines are permissive and the web build of Excel is the strict one. Neither edge is a bug report against anybody — they are conventions — but neither is a thing you want a workbook to pick up from whichever application opened it.

The portable fix

Do not let the branch be chosen for you. Write the convention you want into the formula.

For odd roots of a possibly-negative base, take the root of the magnitude and put the sign back:

=SIGN(A1)*POWER(ABS(A1),B1)

That is a mathematical identity, not a measured result, and it holds for every real A1 whenever B1 is 1/n for an odd integer n: (-x)1/n = -(x1/n) exactly because raising a negative number to an odd power keeps its sign. It never hands POWER a negative base at all, so it cannot trip the documented #NUM! rule in any engine. It has one trap, and it is worth knowing before you paste it everywhere: at A1 = 0 the SIGN factor is 0, so the whole expression is 0 — including in the 0^0 case, where it gives 0 rather than the 1 that Google Sheets and LibreOffice return for POWER(0,0).

If you would rather keep POWER’s own value on the ordinary path and only intervene on the negative-base-odd-root case, spell the condition out:

=IF(AND(A1<0,MOD(ROUND(1/B1,0),2)=1),-POWER(ABS(A1),B1),POWER(A1,B1))

The ROUND is not decoration. MOD(1/B1,2)=1 is asking whether the reciprocal of the exponent is an odd integer, and 1/B1 for B1 = 1/3 is a double that need not land exactly on 3; rounding to the nearest integer first makes the test say what it means. Guard the 0^0 corner separately, since it is a different question:

=IF(AND(A1=0,B1=0),1,POWER(A1,B1))

Both guards were executed as one-off probes on LibreOffice Calc 25.8.7.3 on 2026-09-05, with the deterministic =1111+2222 canary reading back 3333 in the same recalculated workbook. They are not corpus cases, so they do not appear on the function pages:

These probes fix the guards’ behaviour in one engine on one day. They are not evidence about what the guards do in the browser build of Excel, which we have run only over the corpus, nor about the desktop product, which we have never run at all. The reason to prefer them anyway is structural rather than empirical: neither guard ever asks an engine to raise a negative number to a fractional power, or zero to the zero, so neither can be answered differently by engines that disagree about those two cases.

The caret operator carries the same semantics as POWER, so =(-8)^(1/3) and =0^0 land on exactly the same two edges; rewriting one spelling as the other changes nothing. When a workbook moves between applications, grep it for POWER and ^ and check two things about the operands: whether the base can go negative while the exponent is fractional, and whether base and exponent can both be zero. If neither can happen, none of this touches you. If either can, the result may change between a number and an error with nothing on screen to announce it, and a downstream total or chart will inherit whichever the engine chose.

Check before you migrate

A note on which Excel this is. The Excel column in the tables above is Microsoft’s documented behaviour for desktop Excel, as recorded in our test corpus — we do not run desktop Excel, and no value in that column is a measurement. Excel for the web is a different application with its own calculation engine, and that one we do run (recalculated on OneDrive, 2026-09-01); it returned -1.9999999999999998 for =POWER(-8,1/3), matching Google Sheets and all four LibreOffice builds rather than the documented #NUM!, and #NUM! for =POWER(0,0), where Sheets and LibreOffice return 1. Because we have no desktop run to compare against, a disagreement between an Excel-web measurement and the documented column is genuinely ambiguous: it may mean the web engine diverges from the desktop one, or that the documentation is wrong about both. We do not claim to know which.