Nat*_*all 10 javascript floating-point ecma262 ieee-754 ecmascript-5
ECMAScript规范Math.pow具有以下特殊规则:
- 如果x <0且x是有限的且y是有限的并且y不是整数,则结果是NaN.
(http://es5.github.com/#x15.8.2.13)
结果Math.pow(-8, 1 / 3)给出NaN而不是-2
这条规则的原因是什么？是否存在某种更广泛的计算机科学或IEEE推理这一规则的原因,或者它只是TC39/Eich曾经做过的选择？
感谢Amadan与我的交流,我想我现在明白了这个推理.为了后代,我想扩大我们的讨论范围.
我们来看下面的例子:尽管它确实应该是Math.pow(823543, 1 / 7)收益率.这是由必须首先转换为十进制表示的事实引入的不准确性,该十进制表示被截断并且失去精度.当我们处理正数时,这不是一个很糟糕的问题,因为我们仍然得到一个非常接近实际结果的结果.6.99999999999999971 / 70.14285714285714285
然而,一旦我们踏入负面世界,我们就会遇到问题.如果一个JavaScript引擎试图计算Math.pow(-823543, 1 / 7)它,首先需要转换1 / 7为十进制,所以它实际上是计算Math.pow(-823543, 0.14285714285714285)实际上没有真正的答案.在这种情况下,它可能必须返回,NaN因为它找不到实数,即使真正的答案应该是-7.此外,寻找接近实数的复数来做出"最佳猜测"可能涉及一定程度的复杂性,他们不希望JS引擎在数学领域中拥有.
我的猜测是由于考虑到浮点数的精度损失导致他们遵循以下规则:非整数幂的负数应该总是NaN- 基本上因为非整数幂可能给出一个由于精度损失导致的复数,即使它不应该,也可能没有好的方法可以从中恢复.
有了这个,我相当满意,但我确实欢迎进一步的信息.
我认为是因为这些情况导致结果变得复杂，而 ECMAScript 没有配备虚数。具体来说，您的示例应该产生接近1 + 1.732i等结果。（事实上，-2 也是一个可能的结果，这一点不重要——这是一个意外，而不是一个规则。）