Why does 0^0 in the macOS and iOS calculator give different results on different versions?

I have checked the result of 0^0 in the calculator on different versions:

  • iOS 10.3 => 1
  • iOS 11.4 => Error
  • macOS 10.12.6 => 1
  • macOS 10.13.5 => Not a Number

What is the reason for the difference?


While 0⁰ is generally undefined, some branches of mathematics do explicitly define it as 1 because, as you can see, this is the value to which the function y(x) = xˣ converges at n=0.

Less formally, note that 0.50.5=0.707…; 0.20.2=0.725…; 0.10.1=0.794… and 0.010.01=0.955…. As you approach 0, the result will be approaching 1, which makes it quite logical and handy to define 0^0 as 1 in some cases.

Thus, none of these 3 results are incorrect per se and instead they all reflect different conventions on the value of this undefined expression.

There is a good Wikipedia article explaining the issue. See also Zero to the zero power – is 0⁰=1?.


Most implementations of floating point arithmetic follow the IEEE 754-2008 standard, which specifies that pow(0,0) returns 1 (see §9.2.1).

But it also defines two other functions: pown(0,0) = 1 and powr(0,0) = NaN.

Wikipedia summarizes it as follows:

The IEEE 754-2008 floating-point standard is used in the design of most floating-point libraries. It recommends a number of operations for computing a power:[20]

pow treats 00 as 1. If the power is an exact integer the result is the same as for pown, otherwise the result is as for powr (except for some exceptional cases).

pown treats 00 as 1. The power must be an exact integer. The value is defined for negative bases; e.g., pown(−3,5) is −243. powr treats 00 as NaN (Not-a-Number – undefined). The value is also NaN for cases like powr(−3,2) where the base is less than zero. The value is defined by epower×log(base).

The pow variant is inspired by the pow function from C99, mainly for compatibility.[21] It is useful mostly for languages with a single power function. The pown and powr variants have been introduced due to conflicting usage of the power functions and the different points of view (as stated above).[22]

Of course this has no bearing on what the correct mathematical result is: as others have noted, there is more than one possible answer, and IEEE had to make an arbitrary decision.


Somebody at Apple figured out that 0^0 is an invalid operation and got it fixed.


Zero to the power of zero is a contradiction

  • 0 times any number is 0
  • any number to the 0 power is 1

It should generate an error. The only reason that you aren't seeing an error being generated is due to the fact that the version of Calculator in question didn't trap for that input error.


There is some semicontroversy about 0⁰ that boils down to the function x^y having a discontinuity at (x,y)->(0,0). This is a semicontroversy since it is mathematical nonsense to forbid a function having a value at a discontinuity.

It is general practice to embed integers into the reals such that a function defined on the reals matches the same function defined on integers whenever the real function assumes integral values. So there is little point in distinguishing 0.0^0 from 0.0^0.0 .

Now x⁰ with the integer 0 as exponent is a product containing exactly zero factors of x. Since no factors of x are contained in its value, there is little point in assigning it a value depending on x, and its value as an empty product is pretty clearly 1, the neutral element for multiplication.

This makes also good sense since it does not arbitrarily restrict the binomial theorem to non-zero values. In a manner, this is an argument based on trying to complete the function x⁰ sensibly at x=0, making it defined and continuous everywhere.

If we try this with the function 0^x instead, the limit at x=0+ may be 0, but defining it as such still does not help curing the essential discontinuity since the function is undefined for negative x.

Now calculators tend to calculate x^y as exp(y*ln(x)). Of course that is bad news for x=0. So such values have to be explicitly programmed or you'll arrive at not-a-number. For explicit programming, you have to rely on the mathematical intuition of the programmer, and the typical programmer will be more guided by pseudomathematical intuition like "a function must be continuous where defined" than a mathematician would.

In addition, you can expect a flurry of comments from different users, and pure mathematicians will not revert to calculators for their vision of mathematical truth all that much, so you cannot expect their input to swamp that of others.

So the result is a democratic one more than a mathematical one, and democratic majorities tend to change.