PEP 228 – Überarbeitung von Pythons Zahlenmodell
- Autor:
- Moshe Zadka <moshez at zadka.site.co.il>, Guido van Rossum <guido at python.org>
- Status:
- Zurückgezogen
- Typ:
- Standards Track
- Erstellt:
- 04-Nov-2000
- Post-History:
Zurückgezogen
Dieser PEP wurde zugunsten von PEP 3141 zurückgezogen.
Zusammenfassung
Heute ähnelt Pythons Zahlenmodell dem C-Zahlenmodell: Es gibt mehrere nicht miteinander verbundene Zahlentypen, und wenn Operationen zwischen Zahlentypen angefordert werden, findet eine Koerzion statt. Während die Begründung von C für das Zahlenmodell darin liegt, dass es dem entspricht, was auf Hardwareebene geschieht, gilt diese Begründung nicht für Python. Während es für C-Programmierer akzeptabel ist, dass 2/3 == 0 ist, sind viele Python-Programmierer überrascht.
HINWEIS: Angesichts der jüngsten Diskussionen in der Newsgruppe müssen die Motivationen in diesem PEP (und die Details) erweitert werden.
Begründung
In Usability-Studien war die Tatsache, dass die Ganzzahldivision den Boden der Division zurückgibt, einer der am wenigsten nutzbaren Aspekte von Python. Dies erschwert die korrekte Programmierung und erfordert an verschiedenen Stellen im Code die Umwandlung in float(). Pythons Zahlenmodell leitet sich von C ab, während ein Modell, das einfacher zu handhaben ist, auf dem mathematischen Verständnis von Zahlen basieren kann.
Andere Zahlenmodelle
Perls Zahlenmodell besagt, dass es einen Zahlentyp gibt – Gleitkommazahlen. Obwohl es konsistent und oberflächlich nicht überraschend ist, birgt es subtile Fallstricke. Einer davon ist, dass die Ausgabe von Zahlen sehr knifflig ist und eine korrekte Rundung erfordert. In Perl gibt es auch einen Modus, in dem alle Zahlen ganze Zahlen sind. Dieser Modus hat auch seine Probleme, die daraus resultieren, dass es nicht einmal eine ungefähre Möglichkeit gibt, Zahlen zu dividieren und sinnvolle Ergebnisse zu erhalten.
Vorgeschlagene Schnittstelle für Pythons Zahlenmodell
Obwohl Koerzionsregeln für Add-on-Typen und -Klassen weiterhin gelten, wird das integrierte Typsystem genau einen Python-Typ haben – eine Zahl. Es gibt mehrere Dinge, die als „Zahlenmethoden“ betrachtet werden können:
isnatural()isintegral()isrational()isreal()iscomplex()isexact()
Offensichtlich wird eine Zahl, die auf eine Frage von 1 bis 5 mit Ja antwortet, auch auf jede folgende Frage mit Ja antworten. Wenn isexact() nicht wahr ist, kann jede Antwort falsch sein. (Aber nicht extrem falsch: Sie liegt nahe an der Wahrheit.)
Nun versprechen die Modelle zwei Dinge für die Feldoperationen (+, -, /, *)
- Wenn beide Operanden
isexact()erfüllen, erfüllt das Ergebnisisexact(). - Alle Feldregeln sind wahr, außer dass sie für Nicht-
isexact()-Zahlen nur ungefähr wahr sein können.
Eine Folge dieser beiden Regeln ist, dass alle exakten Berechnungen als (komplexe) rationale Zahlen durchgeführt werden: Da die Feldgesetze gelten müssen, gilt
(a/b)*b == a
muss gelten.
Es gibt eine integrierte Funktion, inexact(), die eine Zahl entgegennimmt und eine ungenaue Zahl zurückgibt, die eine gute Annäherung darstellt. Ungenaue Zahlen müssen mindestens so genau sein, als ob sie IEEE-754 verwenden würden.
Mehrere der klassischen Python-Funktionen geben auch bei der Übergabe ungenauer Zahlen exakte Zahlen zurück: z.B. int().
Koerzion
Der Zahlentyp definiert nicht nb_coerce. Jede numerische Operationsschlitz weigert sich, sie zu implementieren, wenn etwas anderes als PyNumber empfangen wird.
Ungenau Operationen
Die Funktionen im Modul math dürfen für exakte Werte ungenaue Ergebnisse zurückgeben. Sie werden jedoch niemals eine nicht-reelle Zahl zurückgeben. Die Funktionen im Modul cmath dürfen ebenfalls ein ungenaues Ergebnis für ein exaktes Argument zurückgeben und außerdem ein komplexes Ergebnis für ein reelles Argument zurückgeben.
Probleme mit Python-Zahlen
Leute, die Numerical Python nutzen, tun dies für leistungsstarke Vektoroperationen. Daher sollte NumPy sein hardwarebasiertes Zahlenmodell beibehalten.
Ungelöste Probleme
Welche Zahlenliterale sind exakt und welche ungenau?
Wie gehen wir mit IEEE 754-Operationen um? (wahrscheinlich sollten isnan/isinf Methoden sein)
Auf 64-Bit-Maschinen können Vergleiche zwischen Integern und Gleitkommazahlen fehlerhaft sein, wenn der Vergleich eine Umwandlung in eine Gleitkommazahl beinhaltet. Dasselbe gilt für Vergleiche zwischen Longs und Gleitkommazahlen. Dies kann vermieden werden, indem die Umwandlung in eine Gleitkommazahl unterbleibt. (Dank Andrew Koenig.)
Urheberrecht
Dieses Dokument wurde gemeinfrei erklärt.
Quelle: https://github.com/python/peps/blob/main/peps/pep-0228.rst
Zuletzt geändert: 2025-02-01 08:55:40 GMT