Das Problem mit binärem Gleitkomma

In der Dezimalmathematik gibt es viele Zahlen, die nicht mit einer festen Anzahl von Dezimalziffern dargestellt werden können, z. B. 1/3 = 0,3333333333…….

In Basis 2 (der Art und Weise, wie die Standard-Gleitkommazahlen berechnet werden) ist 1/2 = 0,1, 1/4 = 0,01, 1/8 = 0,001 usw. Die Dezimalzahl 0,2 entspricht 2/10, was 1/5 entspricht, und ergibt die binäre Bruchzahl 0,001100110011001... Wie Sie sehen können, besteht das Problem darin, dass einige Dezimalzahlen nicht exakt in binärer Form dargestellt werden können, was zu kleinen Rundungsfehlern führt.

Wir brauchen also einen Dezimaldatentyp, der Dezimalzahlen exakt darstellt. Anstelle eines binären Datentyps benötigen wir einen dezimalen.

Warum Gleitkomma?

Also gehen wir zu Dezimalzahlen, aber warum *Gleitkomma*?

Gleitkommazahlen verwenden eine feste Anzahl von Ziffern (Genauigkeit), um eine Zahl darzustellen, und arbeiten mit einem Exponenten, wenn die Zahl zu groß oder zu klein wird. Zum Beispiel mit einer Genauigkeit von 5

  1234 ==>   1234e0
 12345 ==>  12345e0
123456 ==>  12346e1

(beachten Sie, dass in der letzten Zeile die Zahl gerundet wurde, um in fünf Ziffern zu passen).

Im Gegensatz dazu haben wir das Beispiel einer `long`-Ganzzahl mit unendlicher Genauigkeit, was bedeutet, dass Sie die Zahl so groß machen können, wie Sie möchten, und Sie niemals Informationen verlieren.

Bei einer Festkommazahl ist die Position des Dezimalpunkts fixiert. Für einen Festkommadatentyp siehe Tim Peters' FixedPoint auf SourceForge [4]. Ich entscheide mich für Gleitkomma, da es einfacher ist, das arithmetische Verhalten des Standards zu implementieren, und Sie dann einen Festkommadatentyp über Decimal implementieren können.

Aber warum können wir keine Gleitkommazahl mit unendlicher Genauigkeit haben? Das ist nicht so einfach, wegen inexakter Divisionen. Z.B.: 1/3 = 0,3333333333333... ad infinitum. In diesem Fall sollten Sie unendlich viele 3en speichern, was zu viel Speicherplatz kostet ;-).

John Roth schlug vor, den Divisionsoperator abzuschaffen und den Benutzer zu zwingen, eine explizite Methode zu verwenden, nur um diese Art von Problemen zu vermeiden. Dies löste heftige Reaktionen in comp.lang.python aus, da jeder die Unterstützung für den `/`-Operator in einem numerischen Datentyp wünscht.

Mit diesem dargelegten Punkt denken Sie vielleicht: "Hey! Können wir nicht einfach die 1 und die 3 als Zähler und Nenner speichern?", was uns zum nächsten Punkt führt.

Warum nicht rational?

Rationale Zahlen werden mit zwei Ganzzahlen gespeichert, dem Zähler und dem Nenner. Dies bedeutet, dass die arithmetischen Operationen nicht direkt ausgeführt werden können (z. B. um zwei rationale Zahlen zu addieren, muss zuerst der gemeinsame Nenner berechnet werden).

Zitat von Alex Martelli

Die Performance-Implikationen der Tatsache, dass die Summe zweier Rationale (die O(M) und O(N) Speicherplatz beanspruchen) ein Rational ergibt, das O(M+N) Speicherplatz beansprucht, ist einfach zu mühsam. Es gibt ausgezeichnete rationale Implementierungen sowohl in reinem Python als auch als Erweiterungen (z.B. gmpy), aber sie werden meiner Meinung nach immer eine "Nischenmarkt" bleiben. Wahrscheinlich wert für ein PEP, nicht aber ohne Decimal – was der richtige Weg ist, um Geldbeträge darzustellen, ein wirklich wichtiger Anwendungsfall in der realen Welt.

Wenn Sie sich für diesen Datentyp interessieren, möchten Sie vielleicht einen Blick auf PEP 239: Hinzufügen eines rationalen Typs zu Python werfen.

Was haben wir also?

Das Ergebnis ist ein Dezimaldatentyp mit begrenzter Genauigkeit und Gleitkomma.

Wird es nützlich sein? Ich kann es nicht besser sagen als Alex Martelli

Python (out of the box) erlaubt Ihnen nicht, binäre Gleitkommazahlen *mit beliebiger von Ihnen angegebener Genauigkeit* zu haben: Sie sind auf das beschränkt, was Ihre Hardware liefert. Dezimal, sei es als Fest- oder Gleitkommazahl verwendet, sollte keine solche Einschränkung haben: Welche begrenzte Genauigkeit Sie auch immer bei der Zahlenerstellung angeben (sofern Ihr Speicher dies zulässt), sollte genauso gut funktionieren. Der Großteil des Aufwands für Programmiervereinfachung kann vor Anwendungsprogrammen versteckt und in einem geeigneten Dezimalarithmetiktyp untergebracht werden. Laut http://speleotrove.com/decimal/ *kann ein einziger Datentyp für dezimale Ganzzahl-, Festkomma- und Gleitkomm-Arithmetik verwendet werden* – und für Geldbetragsarithmetik, die den Anwendungsprogrammierer nicht verrückt macht.

Es gibt verschiedene Verwendungszwecke für einen solchen Datentyp. Wie bereits erwähnt, werde ich ihn als Basis für Geld verwenden. In diesem Fall ist die begrenzte Genauigkeit kein Problem; Zitat von Tim Peters

Eine Genauigkeit von 20 wäre mehr als ausreichend, um die gesamte Weltwirtschaft, bis auf den letzten Penny, seit Anbeginn der Zeit zu berücksichtigen.

Das arithmetische Modell

Die Spezifikation basiert auf einem Modell der Dezimalarithmetik, wie es von den einschlägigen Standards definiert wird: IEEE 854 [3], ANSI X3-274 [1] und der vorgeschlagenen Überarbeitung [5] von IEEE 754 [6].

Das Modell hat drei Komponenten

• Zahlen: nur die Werte, die die Operation als Eingabe oder Ausgabe verwendet.
• Operationen: Addition, Multiplikation usw.
• Kontext: eine Reihe von Parametern und Regeln, die der Benutzer auswählen kann und die die Ergebnisse von Operationen steuern (z. B. die zu verwendende Genauigkeit).

Zahlen

Zahlen können endlich oder spezielle Werte sein. Erstere können exakt dargestellt werden. Letztere sind Unendlichkeiten und undefiniert (wie 0/0).

Endliche Zahlen werden durch drei Parameter definiert

• Vorzeichen: 0 (positiv) oder 1 (negativ).
• Koeffizient: eine nicht-negative Ganzzahl.
• Exponent: eine vorzeichenbehaftete ganze Zahl, die Zehnerpotenz des Koeffizientenmultiplikators.

Der numerische Wert einer endlichen Zahl ist gegeben durch

(-1)**sign * coefficient * 10**exponent

Spezielle Werte werden wie folgt benannt

• Unendlich: ein Wert, der unendlich groß ist. Kann positiv oder negativ sein.
• Stille NaN ("qNaN"): repräsentiert undefinierte Ergebnisse (*Not a Number*). Verursacht keine "Ungültige Operation"-Bedingung. Das Vorzeichen einer NaN hat keine Bedeutung.
• Signalierende NaN ("sNaN"): ebenfalls *Not a Number*, verursacht aber eine "Ungültige Operation"-Bedingung, wenn sie in irgendeiner Operation verwendet wird.

Kontext

Der Kontext ist eine Reihe von Parametern und Regeln, die der Benutzer auswählen kann und die die Ergebnisse von Operationen steuern (z. B. die zu verwendende Genauigkeit).

Der Kontext erhält diesen Namen, weil er die Dezimalzahlen umschließt, wobei Teile des Kontexts als Eingabe und Ausgabe von Operationen dienen. Es liegt an der Anwendung, mit einem oder mehreren Kontexten zu arbeiten, aber definitiv ist nicht die Idee, einen Kontext pro Dezimalzahl zu haben. Eine typische Verwendung wäre beispielsweise, die Genauigkeit des Kontexts zu Beginn eines Programms auf 20 Ziffern einzustellen und den Kontext nie wieder explizit zu verwenden.

Diese Definitionen beeinträchtigen nicht die interne Speicherung der Dezimalzahlen, sondern nur die Art und Weise, wie die arithmetischen Operationen durchgeführt werden.

Der Kontext wird hauptsächlich durch die folgenden Parameter definiert (siehe Kontextattribute für alle Kontextattribute)

• Genauigkeit: Die maximale Anzahl signifikanter Ziffern, die sich aus einer arithmetischen Operation ergeben können (Ganzzahl > 0). Es gibt keine Obergrenze für diesen Wert.
• Rundung: Der Name des Algorithmus, der verwendet werden soll, wenn eine Rundung erforderlich ist, einer von "round-down", "round-half-up", "round-half-even", "round-ceiling", "round-floor", "round-half-down" und "round-up". Siehe Rundungsalgorithmen unten.
• Flags und Trap-Enabler: Ausnahmezustände sind in Signale gruppiert, die individuell steuerbar sind, wobei jedes aus einem Flag (boolesch, gesetzt, wenn das Signal auftritt) und einem Trap-Enabler (ein boolescher Wert, der das Verhalten steuert) besteht. Die Signale sind: "clamped", "division-by-zero", "inexact", "invalid-operation", "overflow", "rounded", "subnormal" und "underflow".

Standardkontexte

Die Spezifikation definiert zwei Standardkontexte, die für den Benutzer leicht auswählbar sein sollten.

Grundlegender Standardkontext

• Flags: alle auf 0 gesetzt
• Trap-Enabler: inexact, rounded und subnormal sind auf 0 gesetzt; alle anderen sind auf 1 gesetzt
• Genauigkeit: ist auf 9 gesetzt
• Rundung: ist auf round-half-up gesetzt

Erweiterter Standardkontext

• Flags: alle auf 0 gesetzt
• Trap-Enabler: alle auf 0 gesetzt
• Genauigkeit: ist auf 9 gesetzt
• Rundung: ist auf round-half-even gesetzt

Ausnahmezustände

Die folgende Tabelle listet die außergewöhnlichen Bedingungen auf, die während der arithmetischen Operationen auftreten können, das entsprechende Signal und das definierte Ergebnis. Details finden Sie in der Spezifikation [2].

Hinweis: Wenn der Standard von "unzureichendem Speicher" spricht, wird diese Implementierung, solange es sich um eine implementierungsspezifische Verhaltensweise handelt, bei der nicht genügend Speicher vorhanden ist, um die Interna der Zahl zu speichern, eine MemoryError auslösen.

Bezüglich Überlauf und Unterlauf gab es eine lange Diskussion in python-dev über künstliche Grenzen. Der allgemeine Konsens ist, die künstlichen Grenzen nur beizubehalten, wenn wichtige Gründe dafür sprechen. Tim Peters gibt uns drei

...das Eliminieren von Grenzen für Exponenten bedeutet effektiv, dass Überlauf (und Unterlauf) niemals passieren können. Aber Überlauf *ist* ein wertvolles Sicherheitsnetz im realen FP-Gebrauch, wie ein Kanarienvogel in der Kohlemine, der frühzeitig Warnsignale gibt, wenn ein Programm verrückt spielt.

Praktisch alle Implementierungen von 854 verwenden (und wie der IBM-Standard sogar vorschlägt) "verbotene" Exponentenwerte, um nicht-endliche Zahlen (Unendlichkeiten und NaNs) zu kodieren. Ein begrenzter Exponent kann dies mit praktisch keinen zusätzlichen Speicherkosten tun. Wenn der Exponent unbegrenzt ist, müssen stattdessen zusätzliche Bits verwendet werden. Diese Kosten bleiben verborgen, bis zeit- und speichereffizientere Implementierungen versucht werden.

So groß er auch ist, der IBM-Standard ist ein winziger Anfang, um eine vollständige numerische Einrichtung bereitzustellen. Keine Begrenzung der Exponentengröße wird die Implementierung von z. B. Dezimal-Sinus und -Kosinus enorm verkomplizieren (es gibt dann keine a priori Grenze, wie viele Stellen von pi effektiv bekannt sein müssen, um die Argumentreduktion durchzuführen).

Edward Loper gibt uns ein Beispiel dafür, wann die Grenzen überschritten werden sollen: Wahrscheinlichkeiten.

Das heißt, Robert Brewer und Andrew Lentvorski möchten, dass die Grenzen für die Benutzer leicht modifizierbar sind. Das ist tatsächlich gut möglich

>>> d1 = Decimal("1e999999999")     # at the exponent limit
>>> d1
Decimal("1E+999999999")
>>> d1 * 10                         # exceed the limit, got infinity
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in ?
    d1 * 10
  ...
  ...
Overflow: above Emax
>>> getcontext().Emax = 1000000000  # increase the limit
>>> d1 * 10                         # does not exceed any more
Decimal("1.0E+1000000000")
>>> d1 * 100                        # exceed again
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in ?
    d1 * 100
  ...
  ...
Overflow: above Emax

Rundungsalgorithmen

`round-down`: Die verworfenen Ziffern werden ignoriert; das Ergebnis bleibt unverändert (Rundung gegen 0, Trunkierung)

1.123 --> 1.12
1.128 --> 1.12
1.125 --> 1.12
1.135 --> 1.13

`round-half-up`: Wenn die verworfenen Ziffern größer oder gleich der Hälfte (0,5) sind, wird das Ergebnis um 1 erhöht; andernfalls werden die verworfenen Ziffern ignoriert

1.123 --> 1.12
1.128 --> 1.13
1.125 --> 1.13
1.135 --> 1.14

`round-half-even`: Wenn die verworfenen Ziffern größer als die Hälfte (0,5) darstellen, wird der Koeffizient des Ergebnisses um 1 erhöht; wenn sie weniger als die Hälfte darstellen, wird das Ergebnis nicht angepasst; andernfalls bleibt das Ergebnis unverändert, wenn seine letzte Ziffer gerade ist, oder es wird um 1 erhöht, wenn seine letzte Ziffer ungerade ist (um eine gerade Ziffer zu bilden)

1.123 --> 1.12
1.128 --> 1.13
1.125 --> 1.12
1.135 --> 1.14

`round-ceiling`: Wenn alle verworfenen Ziffern Null sind oder wenn das Vorzeichen negativ ist, bleibt das Ergebnis unverändert; andernfalls wird das Ergebnis um 1 erhöht (Rundung gegen unendlich)

 1.123 -->  1.13
 1.128 -->  1.13
-1.123 --> -1.12
-1.128 --> -1.12

`round-floor`: Wenn alle verworfenen Ziffern Null sind oder wenn das Vorzeichen positiv ist, bleibt das Ergebnis unverändert; andernfalls wird der absolute Wert des Ergebnisses um 1 erhöht (Rundung gegen negativ unendlich)

 1.123 -->  1.12
 1.128 -->  1.12
-1.123 --> -1.13
-1.128 --> -1.13

`round-half-down`: Wenn die verworfenen Ziffern größer als die Hälfte (0,5) darstellen, wird das Ergebnis um 1 erhöht; andernfalls werden die verworfenen Ziffern ignoriert

1.123 --> 1.12
1.128 --> 1.13
1.125 --> 1.12
1.135 --> 1.13

`round-up`: Wenn alle verworfenen Ziffern Null sind, bleibt das Ergebnis unverändert, andernfalls wird das Ergebnis um 1 erhöht (Rundung vom 0 weg)

1.123 --> 1.13
1.128 --> 1.13
1.125 --> 1.13
1.135 --> 1.14

Explizite Konstruktion

Die explizite Konstruktion wird vom Kontext nicht beeinflusst (es gibt keine Rundung, keine Präzisionsgrenzen usw.), da der Kontext nur die Ergebnisse von Operationen beeinflusst. Die einzige Ausnahme ist, wenn Sie aus dem Kontext erstellen.

Decimal(35)
Decimal(-124)

Decimal("-12")
Decimal("23.2e-7")

Decimal("Inf")
Decimal("NaN")

(1) says  D(1.1) == D('1.1')
but       1.1 == 1.1000000000000001
so        D(1.1) == D(1.1000000000000001)
together: D(1.1000000000000001) == D('1.1')

d = Decimal (1.1, 1)  # take float value to 1 decimal place
d = Decimal (1.1)  # gets `places` from pre-set context

Decimal.from_float(floatNumber, [decimal_places])

Decimal.from_float(1.1, 2): The same as doing Decimal('1.1').
Decimal.from_float(1.1, 16): The same as doing Decimal('1.1000000000000001').
Decimal.from_float(1.1): The same as doing Decimal('1100000000000000088817841970012523233890533447265625e-51').

Decimal((1, (3, 2, 2, 5), -2))     # for -32.25

Decimal( (0, (0,), 'F') )          # for Infinity
Decimal( (0, (0,), 'n') )          # for Not a Number

Decimal(value1)
Decimal.from_float(value2, [decimal_places])

D.using_context(number, context)

context.create_decimal(number)

# n is any datatype accepted in Decimal(n) plus float
mycontext.create_decimal(n)

>>> # create a standard decimal instance
>>> Decimal("11.2233445566778899")
Decimal("11.2233445566778899")
>>>
>>> # create a decimal instance using the thread context
>>> thread_context = getcontext()
>>> thread_context.prec
28
>>> thread_context.create_decimal("11.2233445566778899")
Decimal("11.2233445566778899")
>>>
>>> # create a decimal instance using other context
>>> other_context = thread_context.copy()
>>> other_context.prec = 4
>>> other_context.create_decimal("11.2233445566778899")
Decimal("11.22")

Implizite Konstruktion

Da die implizite Konstruktion die Folge einer Operation ist, wird sie wie in jedem Punkt detailliert beschrieben vom Kontext beeinflusst.

John Roth schlug vor, dass "Der andere Typ auf die gleiche Weise behandelt werden sollte, wie der decimal()-Konstruktor es tun würde". Aber Alex Martelli denkt, dass

dieser vollständige Bruch mit der Python-Tradition wäre ein furchtbarer Fehler. 23+"43" wird NICHT auf die gleiche Weise behandelt wie 23+int("45"), und das ist auch gut so. Es ist eine völlig andere Sache für einen Benutzer, EXPLICIT zu signalisieren, dass er eine Konstruktion (Konvertierung) möchte, und nur zufällig zwei Objekte zu summieren, von denen eines versehentlich eine Zeichenkette sein könnte.

Daher definiere ich hier das Verhalten für jeden Datentyp neu.

Verwendung von Kontext

Im letzten PEP-Entwurf habe ich gesagt: „Der Kontext muss allgegenwärtig sein, was bedeutet, dass Änderungen daran alle aktuellen und zukünftigen Dezimalinstanzen beeinflussen.“ Ich lag falsch. Als Antwort darauf sagte John Roth:

Der Kontext sollte für den jeweiligen Verwendungszweck auswählbar sein. Das heißt, es sollte möglich sein, mehrere verschiedene Kontexte gleichzeitig in einer Anwendung zu verwenden.

In comp.lang.python erklärte Aahz, dass die Idee darin besteht, einen „Kontext pro Thread“ zu haben. So gehören alle Instanzen eines Threads zu einem Kontext, und Sie können einen Kontext in Thread A (und das Verhalten der Instanzen dieses Threads) ändern, ohne etwas in Thread B zu ändern.

Auch und wieder, um mich zu korrigieren, sagte er:

Der Kontext gilt nur für Operationen, nicht für Dezimalinstanzen; Das Ändern des Kontexts hat keine Auswirkungen auf vorhandene Instanzen, wenn keine Operationen auf ihnen ausgeführt werden.

Tim Peters argumentierte über Sonderfälle, bei denen Operationen mit anderen Regeln als denen des aktuellen Kontexts ausgeführt werden müssen, und sagte, dass der Kontext die Operationen als Methoden haben wird. Auf diese Weise kann der Benutzer „beliebige private Kontextobjekte erstellen, die er benötigt, und die Arithmetik als explizite Methodenaufrufe auf seinen privaten Kontextobjekten buchstabieren, so dass der standardmäßige Thread-Kontext nicht konsultiert oder geändert wird“.

Benutzerfreundlichkeit in Python

• Decimal sollte die grundlegenden arithmetischen (+, -, *, /, //, **, %, divmod) und Vergleichsoperatoren (==, !=, <, >, <=, >=, cmp) in den folgenden Fällen unterstützen (prüfen Sie unter Implizite Konstruktion, welche Typen OtherType sein könnten und was in jedem Fall passiert)
  • Decimal op Decimal
  • Decimal op otherType
  • otherType op Decimal
  • Decimal op= Decimal
  • Decimal op= otherType
• Decimal sollte unäre Operatoren unterstützen (-, +, abs).
• repr() sollte Round-Trip ermöglichen, was bedeutet,

  m = Decimal(...)
  m == eval(repr(m))
  

• Decimal sollte unveränderlich sein.
• Decimal sollte die integrierten Methoden unterstützen
  • min, max
  • float, int, long
  • str, repr
  • hash
  • bool (0 ist falsch, sonst wahr)

Es gab einige Diskussionen in python-dev über das Verhalten von hash(). Die Community ist sich einig, dass, wenn die Werte gleich sind, auch die Hashes dieser Werte gleich sein sollten. Während also Decimal(25) == 25 True ist, sollte hash(Decimal(25)) gleich hash(25) sein.

Das Detail ist, dass Sie Decimal NICHT mit Floats oder Strings vergleichen können, also sollten wir uns keine Sorgen machen, dass diese die gleichen Hashes ergeben. Kurz gesagt:

hash(n) == hash(Decimal(n))   # Only if n is int, long, or Decimal

Bezüglich des Verhaltens von str() und repr() schlägt Ka-Ping Yee vor, dass repr() das gleiche Verhalten wie str() haben sollte, und Tim Peters schlägt vor, dass str() wie die to-scientific-string-Operation aus der Spezifikation funktionieren sollte.

Dies ist möglich, da (von Aahz): „Die Zeichenfolgendarstellung enthält bereits alle notwendigen Informationen, um ein Decimal-Objekt zu rekonstruieren“.

Und es entspricht auch der Spezifikation; Tim Peters

Es gibt keine Anforderung, eine Methode namens "to_sci_string" zu haben, die einzige Anforderung ist, dass *irgendeine* Möglichkeit, die Funktionalität von to-sci-string zu realisieren, bereitgestellt wird. Die Bedeutung von to-sci-string ist genau durch den Standard spezifiziert und ist eine gute Wahl sowohl für str(Decimal) als auch für repr(Decimal).

Dezimalattribute

Decimal hat keine öffentlichen Attribute. Die internen Informationen werden in Slots gespeichert und sollten nicht von Endbenutzern aufgerufen werden.

Dezimalmethoden

Im Folgenden sind die Konvertierungs- und arithmetischen Operationen aufgeführt, die in der Spezifikation definiert sind, und wie diese Funktionalität mit der aktuellen Implementierung erreicht werden kann.

• to-scientific-string: Verwenden Sie die integrierte Funktion str()

  >>> d = Decimal('123456789012.345')
  >>> str(d)
  '1.23456789E+11'
  

• to-engineering-string: Verwenden Sie die Methode to_eng_string()

  >>> d = Decimal('123456789012.345')
  >>> d.to_eng_string()
  '123.456789E+9'
  

• to-number: Verwenden Sie die Kontextmethode create_decimal(). Der Standardkonstruktor oder der from_float() Konstruktor können nicht verwendet werden, da diese den Kontext nicht verwenden (wie in der Spezifikation für diese Konvertierung angegeben).
• abs: Verwenden Sie die integrierte Funktion abs()

  >>> d = Decimal('-15.67')
  >>> abs(d)
  Decimal('15.67')
  

• add: Verwenden Sie den Operator +

  >>> d = Decimal('15.6')
  >>> d + 8
  Decimal('23.6')
  

• subtract: Verwenden Sie den Operator -

  >>> d = Decimal('15.6')
  >>> d - 8
  Decimal('7.6')
  

• compare: Verwenden Sie die Methode compare(). Diese Methode (und nicht die integrierte Funktion cmp()) sollte nur bei der Behandlung von *Spezialwerten* verwendet werden.

  >>> d = Decimal('-15.67')
  >>> nan = Decimal('NaN')
  >>> d.compare(23)
  '-1'
  >>> d.compare(nan)
  'NaN'
  >>> cmp(d, 23)
  -1
  >>> cmp(d, nan)
  1
  

• divide: Verwenden Sie den Operator /

  >>> d = Decimal('-15.67')
  >>> d / 2
  Decimal('-7.835')
  

• divide-integer: Verwenden Sie den Operator //

  >>> d = Decimal('-15.67')
  >>> d // 2
  Decimal('-7')
  

• max: Verwenden Sie die Methode max(). Verwenden Sie diese Methode (und nicht die integrierte Funktion max()) nur bei der Behandlung von *Spezialwerten*.

  >>> d = Decimal('15')
  >>> nan = Decimal('NaN')
  >>> d.max(8)
  Decimal('15')
  >>> d.max(nan)
  Decimal('NaN')
  

• min: Verwenden Sie die Methode min(). Verwenden Sie diese Methode (und nicht die integrierte Funktion min()) nur bei der Behandlung von *Spezialwerten*.

  >>> d = Decimal('15')
  >>> nan = Decimal('NaN')
  >>> d.min(8)
  Decimal('8')
  >>> d.min(nan)
  Decimal('NaN')
  

• minus: Verwenden Sie den unären Operator -

  >>> d = Decimal('-15.67')
  >>> -d
  Decimal('15.67')
  

• plus: Verwenden Sie den unären Operator +

  >>> d = Decimal('-15.67')
  >>> +d
  Decimal('-15.67')
  

• multiply: Verwenden Sie den Operator *

  >>> d = Decimal('5.7')
  >>> d * 3
  Decimal('17.1')
  

• normalize: Verwenden Sie die Methode normalize()

  >>> d = Decimal('123.45000')
  >>> d.normalize()
  Decimal('123.45')
  >>> d = Decimal('120.00')
  >>> d.normalize()
  Decimal('1.2E+2')
  

• quantize: Verwenden Sie die Methode quantize()

  >>> d = Decimal('2.17')
  >>> d.quantize(Decimal('0.001'))
  Decimal('2.170')
  >>> d.quantize(Decimal('0.1'))
  Decimal('2.2')
  

• remainder: Verwenden Sie den Operator %

  >>> d = Decimal('10')
  >>> d % 3
  Decimal('1')
  >>> d % 6
  Decimal('4')
  

• remainder-near: Verwenden Sie die Methode remainder_near()

  >>> d = Decimal('10')
  >>> d.remainder_near(3)
  Decimal('1')
  >>> d.remainder_near(6)
  Decimal('-2')
  

• round-to-integral-value: Verwenden Sie die Methode to_integral()

  >>> d = Decimal('-123.456')
  >>> d.to_integral()
  Decimal('-123')
  

• same-quantum: Verwenden Sie die Methode same_quantum()

  >>> d = Decimal('123.456')
  >>> d.same_quantum(Decimal('0.001'))
  True
  >>> d.same_quantum(Decimal('0.01'))
  False
  

• square-root: Verwenden Sie die Methode sqrt()

  >>> d = Decimal('123.456')
  >>> d.sqrt()
  Decimal('11.1110756')
  

• power: Verwenden Sie den Operator **

  >>> d = Decimal('12.56')
  >>> d ** 2
  Decimal('157.7536')
  

Im Folgenden sind weitere Methoden aufgeführt und warum sie existieren:

• adjusted(): Gibt den angepassten Exponenten zurück. Dieses Konzept ist in der Spezifikation definiert: Der angepasste Exponent ist der Wert des Exponenten einer Zahl, wenn diese Zahl so ausgedrückt wird, als ob sie in wissenschaftlicher Notation mit einer Ziffer vor einem Dezimalpunkt stünde.

  >>> d = Decimal('12.56')
  >>> d.adjusted()
  1
  

• from_float(): Klassenmethode zum Erstellen von Instanzen aus Float-Datentypen.

  >>> d = Decimal.from_float(12.35)
  >>> d
  Decimal('12.3500000')
  

• as_tuple(): Zeigt die interne Struktur des Dezimaltyps, das Triple-Tupel. Diese Methode ist nicht von der Spezifikation gefordert, aber Tim Peters hat sie vorgeschlagen und die Community stimmte ihrer Aufnahme zu (sie ist nützlich für Entwicklung und Debugging).

  >>> d = Decimal('123.4')
  >>> d.as_tuple()
  (0, (1, 2, 3, 4), -1)
  >>> d = Decimal('-2.34e5')
  >>> d.as_tuple()
  (1, (2, 3, 4), 3)
  

Kontextattribute

Dies sind die Attribute, die geändert werden können, um den Kontext zu modifizieren.

• prec (int): die Präzision

  >>> c.prec
  9
  

• rounding (str): Rundungstyp (wie gerundet wird)

  >>> c.rounding
  'half_even'
  

• trap_enablers (dict): Wenn trap_enablers[exception] = 1 ist, wird eine Ausnahme ausgelöst, wenn sie verursacht wird.

  >>> c.trap_enablers[Underflow]
  0
  >>> c.trap_enablers[Clamped]
  0
  

• flags (dict): Wenn eine Ausnahme verursacht wird, wird flags[exception] inkrementiert (unabhängig davon, ob der trap_enabler gesetzt ist). Sollte vom Benutzer der Decimal-Instanz zurückgesetzt werden.

  >>> c.flags[Underflow]
  0
  >>> c.flags[Clamped]
  0
  

• Emin (int): minimaler Exponent

  >>> c.Emin
  -999999999
  

• Emax (int): maximaler Exponent

  >>> c.Emax
  999999999
  

• capitals (int): boolesches Flag zur Verwendung von 'E' (True/1) oder 'e' (False/0) in der Zeichenfolge (z.B. '1.32e+2' oder '1.32E+2').

  >>> c.capitals
  1
  

Kontextmethoden

Die folgenden Methoden entsprechen der Decimal-Funktionalität aus der Spezifikation. Beachten Sie, dass die Operationen, die über einen bestimmten Kontext aufgerufen werden, diesen Kontext und nicht den Thread-Kontext verwenden.

Um diese Methoden zu verwenden, beachten Sie, dass sich die Syntax ändert, wenn der Operator binär oder unär ist, zum Beispiel:

>>> mycontext.abs(Decimal('-2'))
'2'
>>> mycontext.multiply(Decimal('2.3'), 5)
'11.5'

Die folgenden sind also die Spec-Operationen und -Konvertierungen und wie sie über einen Kontext erreicht werden (wobei d eine Dezimalinstanz ist und n eine Zahl, die in einer impliziten Konstruktion verwendet werden kann)

• to-scientific-string: to_sci_string(d)
• to-engineering-string: to_eng_string(d)
• to-number: create_decimal(number), siehe Explizite Konstruktion für number.
• abs: abs(d)
• add: add(d, n)
• subtract: subtract(d, n)
• compare: compare(d, n)
• divide: divide(d, n)
• divide-integer: divide_int(d, n)
• max: max(d, n)
• min: min(d, n)
• minus: minus(d)
• plus: plus(d)
• multiply: multiply(d, n)
• normalize: normalize(d)
• quantize: quantize(d, d)
• remainder: remainder(d)
• remainder-near: remainder_near(d)
• round-to-integral-value: to_integral(d)
• same-quantum: same_quantum(d, d)
• square-root: sqrt(d)
• power: power(d, n)

Die Methode divmod(d, n) unterstützt Dezimalfunktionalität über den Kontext.

Dies sind Methoden, die nützliche Informationen aus dem Kontext zurückgeben:

• Etiny(): Minimaler Exponent unter Berücksichtigung der Präzision.

  >>> c.Emin
  -999999999
  >>> c.Etiny()
  -1000000007
  

• Etop(): Maximaler Exponent unter Berücksichtigung der Präzision.

  >>> c.Emax
  999999999
  >>> c.Etop()
  999999991
  

• copy(): Gibt eine Kopie des Kontexts zurück.