Math.pow mit negativen zahlen und nicht-ganzzahlige Potenzen

Der ECMAScript-Spezifikation für Math.pow hat folgende eigenartige Regel:

  • Wenn x < 0 und x endlich ist und y endlich ist und y ist keine ganze Zahl, ist das Ergebnis NaN.

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

Als Ergebnis Math.pow(-8, 1 /3) gibt NaN eher als -2

Was ist der Grund für diese Regel? Gibt es irgendeine Art von breiteren informatik oder IEEEish Grund für diese Regel, oder ist es nur eine Wahl TC39/Eich aus once upon a time?

Update

Dank Amadan ist der Austausch mit mir, ich glaube, ich verstehe die Argumentation jetzt. Ich möchte erweitern auf unsere Diskussion zum Wohle der Nachwelt.

Nehmen wir das folgende Beispiel: Math.pow(823543, 1 /7) Erträge 6.999999999999999 obwohl es wirklich so sein sollte 7. Dies ist eine Ungenauigkeit eingeführt durch die Tatsache, dass 1 /7 müssen zunächst konvertiert werden, um eine dezimale Darstellung 0.14285714285714285, die abgeschnitten und verliert an Präzision. Das ist nicht so eine schlechte problem, wenn wir arbeiten mit positiven zahlen, denn wir bekommen immer noch ein Ergebnis, das sehr nahe am realen Ergebnis.

Sobald wir jedoch den Schritt in die negative Welt, in der wir ein problem haben. Wenn eine JavaScript-engine wurden, um zu versuchen, um zu berechnen Math.pow(-823543, 1 /7) würde es zuerst konvertieren zu müssen 1 /7 in eine Dezimalzahl, so wäre es wirklich computing Math.pow(-823543, 0.14285714285714285) die eigentlich hat keine wirkliche Antwort. In diesem Fall kann es zurück NaN da Sie nicht finden konnte eine reelle Zahl, obwohl die eigentliche Antwort sollte -7. Darüber hinaus, auf der Suche nach komplexen zahlen, die nahe an den realen zahlen, um einen "best guess" kann bedeuten, eine Ebene der Komplexität, die Sie nicht möchten, dass eine JS-engine zu haben, die in der Mathe-arena.

Meine Vermutung ist, es ist aufgrund der Berücksichtigung des Verlust der Genauigkeit bei floating-point-zahlen, führte Sie zu der Regel, dass negative zahlen eine nicht-ganzzahlige Potenz sollte immer NaN - im Grunde, weil ein nicht-integer-Leistung ist wahrscheinlich zu geben, eine komplexe Zahl, die als Folge von Verlust an Präzision, auch wenn es nicht sollte, und es kann kein guter Weg, um sich zu erholen.

Mit diesem bin ich ziemlich zufrieden, aber ich begrüße weitere Informationen.

InformationsquelleAutor Nathan Wall | 2013-01-29
  1. 4

    Ich vermute, weil diese Umstände führen das Ergebnis in die komplexen Gewässer-und ECMAScript ist nicht ausgestattet mit imaginären zahlen. Insbesondere dein Beispiel sollte das Ergebnis in etwas in der Nähe von 1 + 1.732i, unter anderem Ergebnisse. (Die Tatsache, dass die -2 ist auch eine mögliche Folge ist neben dem Punkt - es ist ein Unfall eher als eine Regel.)

    • Huh? Es ist eine wirkliche Antwort. -2. Es ist gut zu geben NaN wenn es keine wirkliche Antwort. Aber wenn es eine wirkliche Antwort, warum nicht geben Sie es mir?
    • Um genauer zu sein: Math.pow(8, 1 / 3) hat zwei komplexe Antworten und eine richtige Antwort. In diesem Fall JavaScript ist glücklich, mir zu geben die richtige Antwort 2, obwohl es andere Antworten. Was ist der Unterschied?
    • Sorry, ich habe editiert, um Ihr Punkt. Zum Beispiel (-8) ^ (4.32) nicht eine praktische Lösung; und ich nehme an, dass rooting aus (heh, heh) die Fälle, in denen eine rationale Lösung ist außerhalb der Spezifikation.
    • Gutes gegen-Beispiel. Deine Antwort hat mir geholfen, zu denken, durch die es einige mehr, und ich glaube, ich verstehe jetzt, warum es der Fall ist. Fraktionen müssen konvertiert werden, um floating-point-zahlen, und aufgrund von Einschränkungen in der Genauigkeit von floats ist, wäre es einfach für eine Berechnung werden immer so leicht aus, so dass eine echte wurde Komplex und JS zurückkehren musste, NaN eher als eine enge vernünftiges Ergebnis. In diesem Fall raten kann zu fehleranfällig. Danke!!!
    • Vielen Dank für diese. War mit den gleichen Problem in SQL Server, und war ratlos.
    InformationsquelleAutor Amadan
  2. 0

    Können Sie eine Hilfsfunktion.

    Swift Stand ich vor einer ähnlichen situation. Hier ist eine vorgeschlagene Lösung für Sie

    func checkSquareRoot(x: Double, y: Double) -> Double {
    let result = pow(x, y)

    if x > 0 {
        return result
    } else {
        return -1 * pow( -x, y)
    }
}
    InformationsquelleAutor Abdulla
Schreibe einen Kommentar