android 内核 libm pow(float,float) 实现
我正在测试 pow 调用 (#include) 的极端情况，特别是 pow(-1, Inf)。
在我的桌面 (Ubuntu) 上，我得到的结果是 1.0，这符合 2008 年 IEEE 浮点规范。
我在运行 Android Gingerbread 内核时运行相同的测试，并返回 NaN。
我环顾四周，发现不同平台的标准库中确实有许多 pow 的实现，在 pow(-1, Inf) 的情况下，它们被编码产生不同的结果。
问题是哪一个应该被认为是正确的？有什么想法或想法吗？
如果我在错误的论坛上发帖，我深表歉意，我点击了 Android 开发人员资源中的链接并最终来到了这里。
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 IEEE 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
C 标准在这一点上非常清楚（§F.9.4.4）；没有“想法或想法”的空间：
仅当实现定义了
__STDC_IEC_559__时，附录 F 才适用，但毫无疑问 1.0 是正确答案。我怀疑这是一种已经渗透到 NDK 中的 Java 主义。 （Java 将
pow(-1,infinity)定义为NaN）：编辑：
由于马泰奥反对这“毫无意义”，我将用几句话解释委员会为何做出这一选择。虽然 lim_{n->inf} (-1)^n 不存在于实数中，但我们必须记住浮点数不是实数，事实上，对于所有充分的大浮点数
y，pow(-1,y)为+1。这是因为所有足够大的浮点数都是偶数。从这个角度来看，将pow(-1,infinity)定义为+1是相当合理的，事实证明这实际上会在某些浮动中带来更有用的行为点计算。C 委员会和 IEEE-754 委员会中有数量惊人的极其有能力的数学家（以及非常熟练的程序员和编译器编写者），他们不会轻率地做出这些决定。每个标准都有错误，但这不是其中之一。
The C standard is perfectly clear on this point (§F.9.4.4); there's no room for "ideas or thoughts":
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 beNaN):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 definepow(-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.