admin管理员组文章数量:1336402
IEEE 754 defines 1 ^ n as 1, regardless of n. (I'm not paying $106 to confirm this for myself, but this paper cites page 44 from the 2008 standard for this claim.) Most programming languages seem to follow this prescription: Python, C, C#, PHP, Go, and Rust all return 1 for 1 ^ NaN. However, Java and Javascript both return NaN.
- Why does IEEE 754 create this exception to the general rule of NaN propagation?
- Why do Java and Javascript not follow the standard?
IEEE 754 defines 1 ^ n as 1, regardless of n. (I'm not paying $106 to confirm this for myself, but this paper cites page 44 from the 2008 standard for this claim.) Most programming languages seem to follow this prescription: Python, C, C#, PHP, Go, and Rust all return 1 for 1 ^ NaN. However, Java and Javascript both return NaN.
- Why does IEEE 754 create this exception to the general rule of NaN propagation?
- Why do Java and Javascript not follow the standard?
2 Answers
Reset to default 1While IEEE requires money to read the document, well, there are sources where the standard text is leaked. You may find them and consult. Yes, it explicitly recommends (pow is not in "strictly required" section but the standard recommendation weighs much) that pow(+1, y) is 1 for any y, literally, "even a quiet NaN". Both 2008 and 2019 versions have the same requirement.
OTOH, 1985 version, as far as I see, hadnʼt listed pow function at all. (Nor sin, nor atan2, nor any other more advanced than sqrt; the standard was too basic.) So this was, in practice, delegated to implementors, among with multiple other functions and operations. Java and Javascript started in mid-90s and had implemented not the standard but a common convention among different authorities. Both implement even not full 754-1985; you havenʼt seen rounding control context in Java or Javascript core floating support, have you? So, even 1985 version is not what they tend to satisfy to.
You may, of course, file a change (bug, feature) request to fix this but I tend to forecast this will sink in a larger issue whether they want, in principle, to follow IEEE exact letter.
I am not on the IEEE 754 board, yet have used/studied the standard for decades.
Even if reasonable as an opinion, of course this is not authoritative.
Why does IEEE 754 create this exception to the general rule of NaN propagation?
Consider IEEE 754 defines 00 as 1.0 when 0.0, 1.0, infinity, undefined, etc. are all math candidates. There simply is not a universal math result, yet for a computational result, returning 1 satisfies most computational uses.
IMO, this applies here, but even more so. The idea the NaN represents some quantity x of non-deterministic sign and magnitude (potentially infinite) real and imaginary. In all those case 1x results in 1.0. So even with NaN, a result of 1.0 is at least reasonable.
Why do Java and Javascript not follow the standard?
Likely it was simply to code that way and that initial choice stuck.
Perhaps the designers were also off put by the spec's price and did not consider this corner case's ramifications.
本文标签： Why does IEEE 754 define 1NaN as 1and why do Java and Javascript violate thisStack Overflow
版权声明：本文标题：Why does IEEE 754 define 1 ^ NaN as 1, and why do Java and Javascript violate this? - Stack Overflow 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.betaflare.com/web/1742404967a2468633.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
Math: "The special case behavior of the recommended operations generally follows the guidance of the IEEE 754 standard. However, thepowmethod defines different behavior for some arguments, as noted in its specification." and from the specification: "If the second argument is NaN, then the result is NaN." – user85421 Commented Nov 19, 2024 at 20:06powandMath.Powrespectively) with language definitions. – Blindy Commented Nov 19, 2024 at 20:09^), but the power of (Math#pow) method - "IEEE 754 defines 1 ^ n as 1, regardless of n" does not make sense if XOR is meant by "^" – user85421 Commented Nov 20, 2024 at 17:35