Warum liefert 0 ^ 0 im MacOS- und iOS-Rechner bei verschiedenen Versionen unterschiedliche Ergebnisse?

Ich habe das Ergebnis von 0 ^ 0 im Taschenrechner auf verschiedenen Versionen überprüft:

• iOS 10.3 => 1
• iOS 11.4 => Fehler
• macOS 10.12.6 => 1
• macOS 10.13.5 => Keine Nummer

Was ist der Grund für den Unterschied?

Während 0⁰ im Allgemeinen undefiniert ist, wird es in einigen Zweigen der Mathematik explizit als 1 definiert , da dies, wie Sie sehen können , der Wert ist, gegen den die Funktion y (x) = x at bei n = 0 konvergiert.

Weniger formal, beachten Sie, dass 0,5 ^0,5 = 0,707…; 0,2 ^0,2 = 0,725…; 0,1 ^0,1 = 0,794… und 0,01 ^0,01 = 0,955…. Wenn Sie sich 0 nähern, nähert sich das Ergebnis 1, was es sehr logisch und praktisch macht , 0 ^ 0 in einigen Fällen als 1 zu definieren .

Keines dieser 3 Ergebnisse ist per se falsch und spiegelt stattdessen unterschiedliche Konventionen über den Wert dieses undefinierten Ausdrucks wider.

Es gibt einen guten Wikipedia-Artikel , der das Problem erklärt. Siehe auch Null gegen Null - ist 0⁰ = 1? .

Die meisten Implementierungen von Gleitkomma-Arithmetik folgen dem IEEE 754-2008-Standard, der angibt, dass pow (0,0) 1 zurückgibt (siehe §9.2.1).

Es definiert aber auch zwei andere Funktionen: pown (0,0) = 1 und powr (0,0) = NaN.

Wikipedia fasst es wie folgt zusammen :

Der Gleitkomma-Standard IEEE 754-2008 wird beim Entwurf der meisten Gleitkomma-Bibliotheken verwendet. Es empfiehlt eine Reihe von Operationen zur Berechnung einer Leistung:

pow behandelt 0 ⁰ als 1. Wenn die Potenz eine exakte ganze Zahl ist, ist das Ergebnis dasselbe wie für pown, andernfalls ist das Ergebnis wie für powr (mit Ausnahme einiger Ausnahmefälle).

pown behandelt 0 ⁰ als 1. Die Potenz muss eine exakte Ganzzahl sein. Der Wert ist für negative Basen definiert; Zum Beispiel ist pown (-3,5) -243. powr behandelt 0 ⁰ als NaN (Not-a-Number - undefiniert). Der Wert ist auch NaN für Fälle wie powr (−3,2), in denen die Basis kleiner als Null ist. Der Wert wird durch epower × log (Basis) definiert.

Die Pow-Variante ist vor allem aus Kompatibilitätsgründen von der Pow-Funktion von C99 inspiriert. [21] Es ist vor allem für Sprachen mit einer einzigen Potenzfunktion nützlich. Die pown- und powr-Varianten wurden aufgrund der widersprüchlichen Verwendung der Potenzfunktionen und der unterschiedlichen Sichtweisen (wie oben angegeben) eingeführt. [22]

Dies hat natürlich keinen Einfluss auf das richtige mathematische Ergebnis: Wie andere angemerkt haben, gibt es mehr als eine mögliche Antwort, und die IEEE musste eine willkürliche Entscheidung treffen.

Jemand bei Apple hat herausgefunden, dass 0 ^ 0 eine ungültige Operation ist und hat sie behoben.

Null hoch null ist ein Widerspruch

• 0 mal jede Zahl ist 0
• Jede Zahl nach der 0-Potenz ist 1

Es sollte einen Fehler erzeugen. Der einzige Grund, warum kein Fehler generiert wird, ist die Tatsache, dass die betreffende Version von Calculator diesen Eingabefehler nicht abgefangen hat.

Es gibt eine Semikontroverse um 0⁰, die auf die Funktion x ^ y mit einer Diskontinuität bei (x, y) -> (0,0) hinausläuft. Dies ist eine Semikontroverse, da es ein mathematischer Unsinn ist, eine Funktion mit einem Wert in einer Diskontinuität zu verbieten.

Es ist allgemeine Praxis, ganze Zahlen in die reellen Zahlen so einzubetten, dass eine auf den reellen Zahlen definierte Funktion mit derselben auf den ganzen Zahlen definierten Funktion übereinstimmt, wenn die reelle Funktion ganzzahlige Werte annimmt. Es macht also wenig Sinn, 0,0 ^ 0 von 0,0 ^ 0,0 zu unterscheiden.

Nun ist x⁰ mit der ganzen Zahl 0 als Exponent ein Produkt, das genau null Faktoren von x enthält. Da in seinem Wert keine Faktoren von x enthalten sind, macht es wenig Sinn, ihm einen Wert in Abhängigkeit von x zuzuweisen, und sein Wert als leeres Produkt ist ziemlich klar 1, das neutrale Element für die Multiplikation.

Dies ist auch sinnvoll, da es den Binomialsatz nicht willkürlich auf Werte ungleich Null beschränkt. In gewisser Weise ist dies ein Argument, das auf dem Versuch basiert, die Funktion x⁰ bei x = 0 sinnvoll zu vervollständigen und sie überall definiert und stetig zu machen.

Wenn wir dies stattdessen mit der Funktion 0 ^ x versuchen, kann die Grenze bei x = 0 + 0 sein, aber die Definition als solche hilft immer noch nicht, die wesentliche Diskontinuität zu heilen, da die Funktion für negatives x undefiniert ist.

Jetzt neigen Taschenrechner dazu, x ^ y als exp (y * ln (x)) zu berechnen. Das sind natürlich schlechte Nachrichten für x = 0. Solche Werte müssen also explizit programmiert werden, sonst kommen Sie zu einer Nicht-Zahl. Für eine explizite Programmierung müssen Sie sich auf die mathematische Intuition des Programmierers verlassen, und der typische Programmierer lässt sich eher von einer pseudomathematischen Intuition leiten, wie beispielsweise "eine Funktion muss dort, wo sie definiert ist, stetig sein", als dies ein Mathematiker tun würde.

Darüber hinaus können Sie eine Vielzahl von Kommentaren von verschiedenen Benutzern erwarten, und reine Mathematiker werden nicht allzu oft auf Taschenrechner zurückgreifen, um die mathematische Wahrheit zu erkennen.

Das Ergebnis ist also eher eine demokratische als eine mathematische, und demokratische Mehrheiten tendieren dazu, sich zu ändern.