Note - this is not necessary for certification. But for those interested anyway:
Re: Math.pow(-1.0, -1.0)
From the 1.2 API:
"An exception also will occur if (a <= 0.0) and b is not equal to a whole number."<br /> But b
is a whole number: -1. So this rule does not apply. (Yes, it's represented as a double since that's the required argument type for pow() and the args would be promoted to double in any event, but the value still is that of a whole number).<br /> In general, x^(-y) = 1 / (x^y) (where ^ represents exponentiation, not a bitwise XOR
) So (-1)^(-1) = 1 / (-1)^1 = 1 / -1 = -1.<br /> Many calculators will object to any negative value for the first argument, because they don't know how to deal with it. But if the calculator is sufficiently sophisticated, it can often handle this as well - as can Java. The only problem is if the base is negative and the power is fractional - as in (-1)^(0.5), otherwise known as the square root of negative one. This type of operation would require imaginary numbers to compute, which can not be represented by returning a double value, so Java throws an ArithmeticException in this case.<br /> For the record,
my calculator gives -1 as the answer. Then again, my calculator is from Hewlett-Packard, and is perfectly capable of taking the square root of -1 as well.
<br /> <hr><br /> Now as for Math.pow(0.0, 0.0):<br /> In this case, the 1.2 API does clearly indicate that an ArithmeticException is thrown, and it's not. So jdk 1.2.2 does not comply with its own specs here.
This is fixed in 1.3 by changing the specs. The new API lists numerous special cases, including:<br /> "If the second argument is positive or negative zero, then the result is 1.0."<br /> ...which describes our result nicely.<br /> The only problem is, I think it would be better if this threw an error, or returned NaN. Because there are several general rules for computing powers which seem to apply: <br /> x^0 = 1 <br /> 0^y = 0 for y > 0
0^y = Infinity for y < 0
So what happens when both x and y are 0? In calculus terms, it's a limit problem that depends on the order in which you take the limits - which means it's undefined. Java chooses to define it by letting the first rule overrule the second, which makes some sense as the second pair is discontinous and undefined anyway at y = 0. But my trusty calculator throws an error in this case, so naturally I'm inclined to think that's more appropriate. (Hey, would HP lie?)
Plus, that's what the 1.2 specs say. Ah well...