Why is math.pow not natively able to deal with ints? (floor/ceil, too)

Question

I know that in Java (and probably other languages), Math.pow is defined on doubles and returns a double. I'm wondering why on earth the folks who wrote Java didn't also write an int-returning pow(int, int) method, which seems to this mathematician-turned-novice-programmer like a forehead-slapping (though obviously easily fixable) omission. I can't help but think that there's some behind-the-scenes reason based on the intricacies of CS that I just don't know, because otherwise... huh?

On a similar topic, ceil and floor by definition return integers, so how come they don't return ints?

Thanks to all for helping me understand this. It's totally minor, but has been bugging me for years.

Answer 1

java.lang.Math is just a port of what the C math library does.

For C, I think it comes down to the fact that CPU have special instructions to do Math.pow for floating point numbers (but not for integers).

Of course, the language could still add an int implementation. BigInteger has one, in fact. It makes sense there, too, because pow tends to result in rather big numbers.

ceil and floor by definition return integers, so how come they don't return ints

Floating point numbers can represent integers outside of the range of int. So if you take a double argument that is too big to fit into an int, there is no good way for floor to deal with it.

Answer 2

From a mathematical perspective, you're going to overflow your integer if it's larger than 2³¹-1, and overflow your long if it's larger than 2⁶⁴-1. It doesn't take much to overflow it, either.

Doubles are nice in that they can represent numbers from ~10^-308 to ~10³⁰⁸ with 53 bits of precision. There may be some fringe conversion issues (such as the next full integer in a double may not exactly be representable), but by and large you're going to get a much larger range of numbers than you would if you strictly dealt with integers or longs.

On a similar topic, ceil and floor by definition return integers, so how come they don't return ints?

For the same reason outlined above - overflow. If I have an integral value that's larger than what I can represent in a long, I'd have to use something that could represent it. A similar thing occurs when I have an integral value that's smaller than what I can represent in a long.

Answer 3

Optimal implementation of integer pow() and floating-point pow() are very different. And C's math library was probably developed around the time when floating-point coprocessors were a consideration. Optimal implementation of floating point operation is to shift the numbers closer to 1 (to force quicker conversion of the power series) and then shift the result back. For integer power, a more accurate result can be had in O(log(p)) time by doing something like this:

// p is a positive integer power set somewhere above, n is the number to raise to power p
int result = 1;
while( p != 0){
    if (p & 1){ 
        result *= n;
    }
    n = n*n; 
    p = p >> 1;
}

Answer 4

Because all ints can be upcast to a double without loss and the pow function on a double is no less efficient that that on an int.

Answer 5

The reason lies behind the implementation of Math.pow() (JNI of default implementation). The CPU has an exponentiation module which works with doubles as input and output. Why should Java convert that for you when you have much better control over this yourself?

For floor and ceil the reasons are the same, but note that:

(int) Math.floor(d) == (int) d;   // d > 0
(int) Math.ceil(d) == -(int)(-d); // d < 0

For most cases (no warranty around or beyond Integer.MAX_VALUE or Integer.MIN_VALUE).

Java leaves you with

(int) Math.pow(a,b)

because the result of Math.pow may even be NaN or Infinity depending on input.