具有负数和非整数幂的Math.pow [英] Math.pow with negative numbers and non-integer powers

问题描述

Math.pow 的ECMAScript规范具有以下特殊规则：

• 如果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.999999999999999 ，但它确实应该是 7 。这是一个不准确的情况，因为 1/7 必须首先转换成十进制表示 0.14285714285714285 ，这是截断和失去精度。当我们使用正数时，这并不是一个很糟糕的问题，因为我们仍然得到了一个非常接近实际结果的结果。

  然而，一旦我们步进入消极的世界，我们有一个问题。如果JavaScript引擎试图计算 Math.pow（-823543,1 / 7），它首先需要将 1/7 到一个小数，所以它真的会计算 Math.pow（-823543,0.114285714285714285）实际上没有真正的答案 。在这种情况下，它可能必须返回 NaN ，因为它找不到实数，即使真实答案应该是 -7 。而且，寻找接近真实数字的复数来做出最好的猜测可能会涉及一些复杂程度，他们不希望JS引擎在数学领域有这样的复杂性。
  
  
  

  我猜这是由于考虑到浮点数的精度损失，导致他们的规则是负数到非整数次方应该总是 NaN - 基本上是因为非整数功能可能会导致一个复杂的数字，因为精度的损失，即使它不应该，并且可能没有好的方法来恢复它。
  
  

  有了这个，我相当满意，但是我确实欢迎你提供更多信息。 / div>我假设因为那些情况导致复杂的水域，并ECMAScript没有配备虚数。具体而言，您的示例应该会导致接近 1 + 1.732i 等其他结果。 （事实上​​-2也是一个可能的结果，除了这一点 - 这是一个意外，而不是一个规则。）

  
  

  The ECMAScript specification for Math.pow has the following peculiar rule:

  • If x < 0 and x is finite and y is finite and y is not an integer, the result is NaN.

  (http://es5.github.com/#x15.8.2.13)

  As a result Math.pow(-8, 1 / 3) gives NaN rather than -2

  What is the reason for this rule? Is there some sort of broader computer science or IEEEish reason for this rule, or is it just a choice TC39/Eich made once upon a time?

  ---

  Update

  Thanks to Amadan's exchanges with me, I think I understand the reasoning now. I would like to expand upon our discussion for the sake of posterity.

  Let's take the following example: Math.pow(823543, 1 / 7) yields 6.999999999999999 although it really should be 7. This is an inaccuracy introduced by the fact that 1 / 7 must first be converted to a decimal representation 0.14285714285714285, which is truncated and loses precision. This isn't such a bad problem when we're working with positive numbers because we still get a result that's extremely close to the real result.

  However, once we step into the negative world we have a problem. If a JavaScript engine were to try to compute Math.pow(-823543, 1 / 7) it would first need to convert 1 / 7 to a decimal, so it would really be computing Math.pow(-823543, 0.14285714285714285) which actually has no real answer. In this case, it may have to return NaN since it couldn't find a real number, even though the real answer should be -7. Futhermore, looking for complex numbers which are close to real numbers to make a "best guess" may involve a level of complexity they didn't want to require a JS engine to have in the math arena.

  My guess is it is due to the consideration of the loss of precision in floating point numbers that led them to the rule that negative numbers to a non-integer power should always be NaN -- basically because a non-integer power is likely to give a complex number as a result of loss of precision, even if it shouldn't, and there may be no good way to recover from it.

  With this, I'm fairly satisfied, but I do welcome further information.

  解决方案

  I assume because those circumstances lead the result into complex waters, and ECMAScript is not equipped with imaginary numbers. Specifically, your example should result in something close to 1 + 1.732i, among other results. (The fact that -2 is also a possible result is besides the point - it is an accident rather than a rule.)

  这篇关于具有负数和非整数幂的Math.pow的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！