android kernel libm pow(float,float) implementation

I am testing corner cases on the pow call(#include <math.h>), specifically pow(-1, Inf).

On my desktop (Ubuntu) I get the result 1.0, this is in accordance with the 2008 IE开发者_C百科EE floating point specification.

I run the same test when running the Android Gingerbread kernel and I get NaN returned.

I have looked around and can see that there is indeed many implementations of pow in the standard libraries for different platforms and in the case pow(-1, Inf) they are coded to produce different results.

The question is which one should be deemed correct? Any Ideas or thoughts?

I apologize if I am posting on the wrong forum, I followed the link from the android developer resources and ended up here.

---

The C standard is perfectly clear on this point (§F.9.4.4); there's no room for "ideas or thoughts":

pow(−1, ±∞) returns 1.

Annex F applies only if an implementation defines __STDC_IEC_559__, but there is no question that 1.0 is the right answer.

I suspect that this is a Java-ism that has leaked over into the NDK. (Java defines pow(-1,infinity) to be NaN):

If the absolute value of the first argument equals 1 and the second argument is infinite, then the result is NaN.

Edit: Since Matteo objects that this "makes no sense", I'll offer a few sentences of explanation for why the committee made this choice. Although lim_{n->inf} (-1)^n does not exist in the real numbers, we must remember that floating-point numbers are not real numbers, and in fact, for all sufficiently large floating-point numbers y, pow(-1,y) is +1. This is because all sufficiently large floating-point numbers are even integers. From this perspective, it is quite reasonable to define pow(-1,infinity) to be +1, and this turns out to actually lead to more useful behavior in some floating-point computations.

There are a surprising number of extremely competent mathematicians (as well as very skilled programmers and compiler writers) involved with both the C and the IEEE-754 committees, and they do not make these decisions flippantly. Every standard has bugs, but this is not one of them.