A negative base with a fractional exponent errors in Excel, computes in LibreOffice
Raising a negative number to a non-integer power is treated as out of domain by Excel, which
returns #NUM!. LibreOffice Calc instead returns the real odd root, so
=POWER(-8,1/3) is a #NUM! error in one app and the number -2 in the
other. This is a genuine fork: an error on one side and a finite value on the other.
The surprise
Excel rejects the whole class of "negative base, fractional exponent" as a numeric-domain error. LibreOffice evaluates the specific case as the real cube root and hands you a number, so a workbook that shows an error in Excel shows a result in LibreOffice.
A minimal example
| Formula | Excel (documented) | Google Sheets | LibreOffice Calc 25.8.7.3 (executed) |
|---|---|---|---|
| =POWER(-8,1/3) | #NUM! | Not yet executed | -2 |
#NUM! is the documented-expected value in our test corpus; -2 is what our harness
computed by recalculating in LibreOffice Calc 25.8.7.3. We have not yet executed this case in Google Sheets.
Why it happens
A negative base raised to a general non-integer exponent has no single real-valued result: the
principal mathematical value is complex. Excel treats that entire class as a numeric-domain error
and returns #NUM!, which is the expected value recorded in our corpus. LibreOffice
resolves this particular exponent as the real odd root and returns -2. The divergence is not a bug
report on either side; it is two defensible conventions for the same undefined-in-reals case. See
Microsoft's
POWER function reference.
How to migrate safely
If you intend the real odd root, make the intent explicit so every engine returns the same number:
=SIGN(-8)*ABS(-8)^(1/3) returns -2 everywhere.
If a negative base is actually invalid input in your model, guard it so the behavior is defined rather than engine-dependent:
=IF(A1<0,"invalid",POWER(A1,B1))
The caret operator behaves the same way as POWER for this case, so =(-8)^(1/3)
also returns #NUM! in Excel and -2 in LibreOffice; rewriting one form does not help
unless you make the sign handling explicit as above.
Either way, do not let a formula rely on one engine erroring and the other computing. After
migrating, look for POWER or ^ over values that can go negative, since the result can
switch between an error and a finite number without warning, and a downstream chart or total will
inherit whichever the engine chose.