In C++ The result of pow(0, 0) the result is basically implementation defined behavior since mathematically we have a contradictory situation where N^0 should always be 1 but 0^N should always be 0 for N > 0, so you should have no expectations mathematically as to the result of this either. This Wolfram Alpha forum posts goes into a bit more details.

Although having pow(0,0) result in 1 is useful for many applications as the Rationale for International Standard—Programming Languages—C states in the section covering IEC 60559 floating-point arithmetic support:

Generally, C99 eschews a NaN result where a numerical value is useful. [...] The results of pow(∞,0) and pow(0,0) are both 1, because there are applications that can exploit this definition. For example, if x(p) and y(p) are any analytic functions that become zero at p = a, then pow(x,y), which equals exp(y*log(x)), approaches 1 as p approaches a.

Update C++

As leemes correctly pointed out I originally linked to the reference for the complex version of pow while the non-complex version claims it is domain error the draft C++ standard falls back to the draft C standard and both C99 and C11 in section 7.12.7.4 The pow functions paragraph complex0 says (complex1):

[...]A domain error may occur if x is zero and y is zero.[...]

which as far as I can tell means this behavior is unspecified behavior Winding back a bit section 7.12.1 Treatment of error conditions says:

[...]a domain error occurs if an input argument is outside the domain over which the mathematical function is defined.[...] On a domain error, the function returns an implementation-defined value; if the integer expression math_errhandling & MATH_ERRNO is nonzero, the integer expression errno acquires the value EDOM; [...]

So if there was a domain error then this would be implementation defined behavior but in both the latest versions of gcc and clang the value of errno is 0 so it is not a domain error for those compilers.

Update Javascript

For Javascript the ECMAScript® Language Specification in section 15.8 The Math Object under 15.8.2.13 pow (x, y) says amongst other conditions that:

If y is +0, the result is 1, even if x is NaN.

In JavaScript Math.pow is defined as follows:

• If y is NaN, the result is NaN.
• If y is +0, the result is 1, even if x is NaN.
• If y is −0, the result is 1, even if x is NaN.
• If x is NaN and y is nonzero, the result is NaN.
• If abs(x)>1 and y is +∞, the result is +∞.
• If abs(x)>1 and y is −∞, the result is +0.
• If abs(x)==1 and y is +∞, the result is NaN.
• If abs(x)==1 and y is −∞, the result is NaN.
• If abs(x)<1 and y is +∞, the result is +0.
• If abs(x)<1 and y is −∞, the result is +∞.
• If x is +∞ and y>0, the result is +∞.
• If x is +∞ and y<0, the result is +0.
• If x is −∞ and y>0 and y is an odd integer, the result is −∞.
• If x is −∞ and y>0 and y is not an odd integer, the result is +∞.
• If x is −∞ and y<0 and y is an odd integer, the result is −0.
• If x is −∞ and y<0 and y is not an odd integer, the result is +0.
• If x is +0 and y>0, the result is +0.
• If x is +0 and y<0, the result is +∞.
• If x is −0 and y>0 and y is an odd integer, the result is −0.
• If x is −0 and y>0 and y is not an odd integer, the result is +0.
• If x is −0 and y<0 and y is an odd integer, the result is −∞.
• If x is −0 and y<0 and y is not an odd integer, the result is +∞.
• If x<0 and x is finite and y is finite and y is not an integer, the result is NaN.

_{emphasis mine}

as a general rule, native functions to any language should work as described in the language specification. Sometimes this includes explicitly "undefined behavior" where it's up to the implementer to determine what the result should be, however this is not a case of undefined behavior.

When you want to know what value you should give to f(a) when f isn't directly computable in a, you compute the limit of f when x tends towards a.

In case of x^y, usual limits tend towards 1 when x and y tend to 0, and especially x^x tends towards 1 when x tends to 0.

See http://www.math.hmc.edu/funfacts/ffiles/10005.3-5.shtml

The C language definition says (7.12.7.4/2):

A domain error may occur if x is zero and y is zero.

It also says (7.12.1/2):

On a domain error, the function returns an implementation-defined value; if the integer expression math_errhandling & MATH_ERRNO is nonzero, the integer expression errno acquires the value EDOM; if the integer expression math_errhandling & MATH_ERREXCEPT is nonzero, the ‘‘invalid’’ floating-point exception is raised.

By default, the value of math_errhandling is MATH_ERRNO, so check errno for the value EDOM.

It is just convention to define it as 1, 0 or to leave it undefined. The definition is wide spread because of the following definition:

ECMA-Script documentation says the following about pow(x,y):

• If y is +0, the result is 1, even if x is NaN.
• If y is −0, the result is 1, even if x is NaN.

[ http://www.ecma-international.org/ecma-262/5.1/#sec-15.8.2.13 ]

According to Wikipedia:

In most settings not involving continuity in the exponent, interpreting 0⁰ as 1 simplifies formulas and eliminates the need for special cases in theorems.

There are several possible ways to treat 0**0 with pros and cons to each (see Wikipedia for an extended discussion).

The IEEE 754-2008 floating point standard recommends three different functions:

• pow treats 0**0 as 1. This is the oldest defined version. 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 0**0 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 0**0 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 exp(power'×log(base)).

Donald Knuth

sort of settled this debate in 1992 with the following:

And went even more into details in his paper Two Notes on Notation.

Basically, while we don't have 1 as the limit of f(x)/g(x) for all not all functions f(x) and g(x), it still makes combinatorics so much simpler to define 0^0=1, and then just make special cases in the few places where you need to consider functions such as 0^x, which are weird anyway. After all x^0 comes up a lot more often.

Some of the best discussions I know of this topic (other than the Knuth paper) are:

• Link
• http://www.quora.com/Mathematics/What-is-math-0-0-math?share=1
• https://math.stackexchange.com/questions/475337/the-binomial-formula-and-the-value-of-00

I'd like to disagree with some of the previous answers' assertion that it's a matter of convention or convenience (covering some special cases for various theorems, etc) that 0^0 be defined as 1 instead of 0.

Exponentiation doesn't actually fit that well with our other mathematical notations, so the definition we all learn leaves room for confusion. A slightly different way of approaching it is to say that a^b (or exp(a, b), if you like) returns the value multiplicatively equivalent to multiplying some other thing by a, repeated b times.

When we multiply 5 by 4, 2 times, we get 80. We've multiplied 5 by 16. So 4^2 = 16.

When you multiply 14 by 0, 0 times, we are left with 14. We've multiplied it 1. Hence, 0^0 = 1.

This line of thinking might also help to clarify negative and fractional exponents. 4^(-2) is a 16th, because 'negative multiplication' is division - we divide by four twice.

a^(1/2) is root(a), because multiplying something by the root of a is half the multiplicative work as multiplying it by a itself - you would have to do it twice to multiply something by 4 = 4^1 = (4^(1/2))^2

For this to understand you need to solve calculus:

Expanding x^x around zero using Taylor series, we get:

So to understand what's going on with limit when x goes to zero, we need to find out what's going on with second term x log(x), because other terms are proportional to x log(x) raised to some power.

We need to use transformation:

Now after this transformation we can use L'Hôpital's rule, which states that:

So differentiating that transformation we get:

So we've calculated that term log(x)*x approaches 0 when x approaches 0. It's easy to see that other consecutive terms also approaches zero and even faster than second term.

So at point x=0, series becomes 1 + 0 + 0 + 0 + ... and thus equals to 1.