Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

PEP 239 – Hinzufügen eines rationalen Typs zu Python

Autor:
Christopher A. Craig <python-pep at ccraig.org>, Moshe Zadka <moshez at zadka.site.co.il>
Status:
Abgelehnt
Typ:
Standards Track
Erstellt:
11. März 2001
Python-Version:
2.2
Post-History:
16-Mär-2001

Inhaltsverzeichnis

Warnung

Dieser PEP wurde abgelehnt.

×

Die im Abschnitt „Rationale“ beschriebenen Anforderungen wurden bis zu einem gewissen Grad durch die Annahme von PEP 327 für Dezimalarithmetik erfüllt. Guido bemerkte auch: „Rationale Arithmetik war die Standard-'exakte' Arithmetik in ABC und sie hat sich nicht wie erwartet entwickelt.“ Siehe die Diskussion auf python-dev vom 17. Juni 2005 [1].

Nachschrift: Mit der Annahme von PEP 3141, „Eine Typenhierarchie für Zahlen“, wurde eine 'rationale' abstrakte Basisklasse für numerische Typen hinzugefügt, mit einer konkreten Implementierung im Modul 'fractions'.

Zusammenfassung

Python hat keinen numerischen Typ mit der Semantik einer unbegrenzt präzisen rationalen Zahl. Dieser Vorschlag erklärt die Semantik eines solchen Typs und schlägt Builtin-Funktionen und Literale zur Unterstützung eines solchen Typs vor. Diese PEP schlägt keine Literale für rationale Zahlen vor; dies ist für eine andere PEP vorgesehen.

Begründung

Obwohl manchmal langsamer und speicherintensiver (im Allgemeinen unbegrenzt so) ist rationale Arithmetik näher am mathematischen Ideal von Zahlen und neigt dazu, ein Verhalten zu zeigen, das für Anfänger weniger überraschend ist. Obwohl viele Python-Implementierungen rationaler Zahlen geschrieben wurden, existieren keine davon im Kern oder sind in irgendeiner Weise dokumentiert. Dies hat sie für Personen, die weniger Python-erfahren sind, viel weniger zugänglich gemacht.

RationalType

Es wird ein neuer numerischer Typ namens RationalType hinzugefügt. Seine unären Operatoren werden das Offensichtliche tun. Binäre Operatoren werden ganze Zahlen und lange ganze Zahlen zu rationalen Zahlen und rationale Zahlen zu Gleitkommazahlen und komplexen Zahlen zwangsweise umwandeln.

Die folgenden Attribute werden unterstützt: .numerator und .denominator. Die Sprachdefinition wird garantieren, dass

r.denominator * r == r.numerator

dass der ggT von Zähler und Nenner 1 ist und der Nenner positiv ist.

Die Methode r.trim(max_denominator) gibt die nächstgelegene rationale Zahl s zu r zurück, so dass abs(s.denominator) <= max_denominator ist.

Die rational()-Builtin-Funktion

Diese Funktion wird die Signatur rational(n, d=1) haben. n und d müssen beides ganze Zahlen, lange ganze Zahlen oder rationale Zahlen sein. Es wird garantiert, dass

rational(n, d) * d == n

Offene Fragen

  • Vielleicht sollte der Typ rat statt rational heißen. Jemand schlug vor, wir hätten „abstrakte“ rein mathematische Typen namens complex, real, rational, integer und „konkrete“ Darstellungstypen mit Namen wie float, rat, long, int.
  • Sollte eine rationale Zahl mit ganzzahligem Wert als Sequenzindex erlaubt sein? Zum Beispiel, sollte s[5/3 - 2/3] äquivalent zu s[1] sein?
  • Sollten shift und mask Operatoren für rationale Zahlen erlaubt sein? Für rationale Zahlen mit ganzzahligen Werten?
  • Marcin ‚Qrczak‘ Kowalczyk fasste die Argumente für und gegen die Vereinigung von ints mit rationalen Zahlen schön auf c.l.py zusammen

    Argumente für die Vereinigung von ints mit rationalen Zahlen

    • Da 2 == 2/1 ist und vielleicht str(2/1) == '2', werden Überraschungen reduziert, bei denen Objekte gleich erscheinen, aber sich unterschiedlich verhalten.
    • / kann frei für Ganzzahldivision verwendet werden, wenn ich *weiß*, dass es keinen Rest gibt (wenn ich falsch liege und es einen Rest gibt, wird es wahrscheinlich später eine Ausnahme geben).

    Argumente dagegen

    • Wenn ich das Ergebnis von / als Sequenzindex verwende, ist es normalerweise ein Fehler, der nicht dadurch versteckt werden sollte, dass das Programm für einige Daten funktioniert, da es für andere Daten fehlschlägt.
    • (Dies setzt voraus, dass int und rational nach der Vereinigung unterschiedliche Typen wären:) Typen sollten selten von Werten abhängen. Es ist einfacher zu verstehen, wenn der Typ einer Variablen bekannt ist: Ich weiß, wie ich ihn verwenden kann. Ich kann feststellen, dass etwas ein int ist und erwarten, dass andere Objekte, die an dieser Stelle verwendet werden, ebenfalls ints sind.
    • (Dies setzt denselben Typ für sie voraus:) Int ist ein guter Typ für sich allein, nicht mit rationalen Zahlen zu mischen. Die Tatsache, dass etwas eine ganze Zahl ist, sollte als Aussage über seinen Typ ausgedrückt werden können. Viele Operationen erfordern ints und akzeptieren keine rationalen Zahlen. Es ist natürlich, sie als unterschiedliche Typen zu betrachten.

Referenzen


Quelle: https://github.com/python/peps/blob/main/peps/pep-0239.rst

Zuletzt geändert: 2025-02-01 08:50:23 GMT