> dahart, you can make your first example arbitrarily close to 0^0, but you can't with the second. (e.g. you can replace 1 with 0.001 in the first case but not the second.)

I'm not sure I understand what you mean there.

For any positive nonzero real value x, x^0=1, right? And 0^x=0 for all x too, yes?

The limit from the positive direction for x^0 is 1, you can get arbitrarily close to zero. The limit from the positive direction for 0^x is 0, and you can also get arbitrarily close to 0 here too.

etatoby's graph with isolines, the red and blue ones, shows those two cases specifically, and yeah, they arrive at 0 with two different values, meaning the answer is indeterminate (but not undefined).

Etatoby is right; 0^0 is indeterminate. I'm not arguing with that at all, it is a fact.

I'm saying I understand why people choose to ignore that 0^0 is indeterminate and choose instead to just define that 0^0=1.

I really like your pown() vs powr() example, because it actually demonstrates how in practice, choosing to return a defined value in some cases is the more practical choice.

That said, I think there's still a conflict even within pown(), even for the integer case, that's what I was getting at. pown(0,x) is 0 for all positive x except 0. Negative x is undefined due to the division by 0, and pown(0,0)=1 simply because 0^0 is chosen to be defined at 1. But if you imagine an integer limit starting from 10 going down to zero, there's a clear pattern:

pown(0,10)=0; pown(0,9)=0; ... pown(0,1)=0

pown(10,0)=1; pown(9,0)=1; ... pown(1,0)=1

IEEE chose to make the pown(x,0) rule more important than the pown(0,x) rule when it comes to x=0, even in the case of integers.