Otherwise, I would try exp(0, NaN) . If there is exp(0,0) == 1 , then we should expect
exp(0, NaN) == 1
There is a rationale for this, and in fact it is necessary for consistent behavior. Despite the lack of an IEEE standard that dictates the behavior of elementary functions with respect to NaN, there is a very basic rule:
If for all finite point numbers x including + inf and -inf (but excluding NaN), we have
f(const1, x) == const2
then (and only then) it is also necessary to return the result without NaN
f(const1, NaN) == const2
Long explanation
This is because NaN represents "undefined" or "any other numeric value from -inf .. inf". What for? Consider the prototype example 0/0. If you take into account the equation
b = a * x
and wants to solve for x . Clear solution
x = b/a
Now, if a == b == 0 , then the original equation has an infinite number of solutions, namely, all finite numbers x . This is why NaN means "unspecified" and 0/0 == NaN . Now, if an undefined number (that is, NaN) enters the function as an argument, it most often causes an “unspecified” answer. The exception is that the output is independent of the input, in which case you need / should not return NaN.
Consider
exp(1, a/b)
This expression is always evaluated as 1 for nonzero a and b , which makes sense from a mathematical point of view, since 1^x in the mathematical sense does not depend on x . So it would also be required numerically for a = 0 or b = 0 (and therefore x=NaN ) to get 1 as well.
So, if you accept that
pow(1,-inf) = pow(1,inf) = 1
it is also necessary to determine
pow(1,NaN) = 1
for consistent behavior. The same applies to pow(0,c) , but also an estimate of the polynomial of degree zero should generate a non-NaN output at the input of NaN.
Note: this reasoning can be applied to any function, including built-in operators.