Intern mit Mantisse Exponent rechnen
-
Stimmt. Diesen Sonderfall muss ich berücksichtigen.
-
@SeppJ sagte in Intern mit Mantisse Exonent rechnen:
- Für manche Spezialanforderungen werden auch andere Basen genommen. Man hört oft, in der Finanzmathematik würde 10 benutzt werden. Ich weiß nicht, ob das rechtliche Gründe hat, ob Finanzler nicht genug Ahnung von Mathe haben, oder beides. ich weiß auch nicht, ob das überhaupt stimmt.
Das hat rechtliche Gründe, da Rechnungen zur Basis 2 andere Ergebnisse z.B. bei der Zinsberechnung ergeben. Konten müssen aber exakt so geführt werden, wie man sie von Hand berechnen würde. Daher muss man das Zehnersystem nutzen. IBM hat bei den neueren POWER CPUs und den z/OS Systemen CPUs verbaut die in Hardware mit dem Zehnersystem rechnen können, und meines Wissen wird dafür kein BCD genutzt wie etwa früher bei den 68k CPUs.
-
@SeppJ sagte in Intern mit Mantisse Exponent rechnen:
- Pro: Du kannst eventuell Geschwindigkeit gewinnen
Ein weiteres Pro ist, dass sich die berechnungsergebnisse damit leichter auch über Architektur- und Compilergrenzen hinweg absolut exakt reproduzierbar machen lassen.
Ein Beispiel, wo so etwas nützlich sein kann, sind Netzwerkspiele, die den gemeinsamen Zustand des Spiels via Lockstep synchronisieren. Hier werden sehr effizient ausschliesslich die Usereingaben zwischen den Clients ausgetauscht, die dann den gemeinsamen Zustand jeder für sich berechnen und natürlich alle zum selben Ergebnis kommen müssen.
-
@It0101 sagte in Intern mit Mantisse Exponent rechnen:
Nächster Gedanke war:
- wenn sich die Exponenten unterscheiden shiftet man einfach die Mantisse mit dem größeren Exponenten nach links bis die Exponenten gleich sind und kann dann die Operation vornehmen.
Moment. Wenn du anfängst, Mantissen zu shiften, dann programmierst du eine Software-Emulation für Floating-Point-Zahlen. Das ist garantiert viel langsamer als die Hardwareroutinen (Es gab früher Zeiten, wo das ein wesentliches Verkaufsargument für Prozessoren war, wenn er entsprechende Hardware hatte, weil das so ungemein schneller war…). Der Trick mit den Integers funktioniert nur, wenn alle Zahlen ungefähr dir gleiche Größenordnung haben. Dann kannst du Geschwindigkeit gewinnen, weil du die Komplexität von Floating-Point-Zahlen eigentlich gar nicht voll ausschöpfst, und daher mit Tricks die Berechnungen in einfachere (und schnellere) Ganzzahlrechnungen umformulieren kannst.
-
Hallo @It0101
Nochmal zum Addieren der Mantissen. Im Double-Format hast Du eine 52 Bit Mantisse. Ich versuchs mal mit einem 4 Bit -Beispiel:
1010
1100
Das musst Du binär als
1.1010
1.1100
interpretieren. Die 1 vor dem Komma wird nicht mitgespeichert, da es im Binärfomat immer eine 1 ist. Das kannst Du jetzt addieren zu:
11.0110
Das kannst Du natürlich nicht so als Mantisse in den Double zurückschreiben, den vor dem Komma steht jetzt 11 und per Definition muss da immer 1 stehen. Das heißt, Du musst die Manitisse um 1 Bit nach rechts schieben und zum Expont eine 1 addieren um die korrekte Double Darstellung zu erhalten:
11.0110 >> 1
= 1.1011
Die 1 vor dem Komma wird nicht mitgespeichert, also bleibt
1011
als Mantisse übrig.
Wenn Du das verstanden hast, braucht Du den Teil mit "1." davorschreiben und beim Ergebnis wieder wegnehmen nicht mehr, Addition und Shift funktioniert auch ohne.
-
Vielen Dank für eure rege Diskussion und Unterstützung. Den Fehler beim Addieren habe ich jetzt auch verstanden.
@SeppJ Ich hatte schon befürchtet dass man bei dem Thema sehr leicht Performance verschenkt und dann letztendlich wieder langsamer ist als der Prozessor wenn er mit Doubles rechnet.
Da ich tatsächlich in der Finanzwelt unterwegs bin, wäre prinzipiell auch eine Basis von 10 zielführender. Und da ist dann die Konvertierung eines Doubles ( die von Außen ins System reinkommen ) wieder aufwändiger.
-
Ich hoffe doch, dass selbst im modernen Finanzwesen ein 64 Bit Integer ausreichend ist, alle vorkommenden Beträge mit großzügig vielen Nachkommastellen auch ohne Exponentialschreibweise darzustellen.
-
Für die meisten normalen Dinge wird es reichen.
Allerdings...MS verwendet für Geld Fixkomma mit Faktor 10000* (auf die Hauptwärhung bezogen, also ein Euro = 10000, ein Cent = 100). Bin mir aber nicht sicher ob das für alle Zwischenergebnisse ausreichend ist. Aber gehen wir mal davon aus dass es reicht.
2^64 / 10000 = 1.8446744e+15
Das "global gross domestic product" 2019 war 142 "trillion" (wie es die Amis verwenden also 1 trillion = 10^12), also 1.42e+14.IMO kann das schnell eng werden. Sowieso wenn man irgendwelche Rechnungen zur Weltwirtschaft macht und diese "unskaliert" machen möchte und da ein bisschen Daten über mehrere Jahre akkumuliert. Möglicherweise sogar wenn es "nur" um Firmen geht die Billionenbeträge in ihrer internen Buchhaltung zigfach im Kreis rum schieben und man irgendwo die Summe aller Ein- oder Ausgänge berechnen muss. Oder richtig fette Day-Trading Sachen + ebenfalls die Summe aller Käufe oder Verkäufe über z.B. ein Jahr. Ich kenne mich in dem Sektor aber zu wenig aus. Mag sein dass ich mich täusche und das unrealistische Annahmen sind
*: Damit meine ich den COM-Standard "Currency" Datentyp und SQL Servers "money" Datentyp. Das heisst natürlich nicht dass alle MS Anwendungen damit arbeiten. Wenn es irgendwas für Buchhaltung von MS gibt, ist davon auszugehen dass die mit der passenden Anzahl Nachkommastellen rechnen die für die jeweilige Legislatur passend ist.
-
Also für mein Projekt hätte ich jetzt 4 NKS ( also 10000 ) als Grundlage genommen und für das saubere Berechnen von Zwischenergebnissen und um die Rundungsfehler nicht zu groß werden zu lassen, nochmal 2 dazu genommen also mit 6 NKS gerechnet. Damit ist man zumindest im Börsenumfeld sauber. Würde ich Zinsberechnung machen hätte ich vielleicht noch mehr genommen.
-
@It0101 sagte in Intern mit Mantisse Exponent rechnen:
Also für mein Projekt hätte ich jetzt 4 NKS ( also 10000 ) als Grundlage genommen und für das saubere Berechnen von Zwischenergebnissen und um die Rundungsfehler nicht zu groß werden zu lassen, nochmal 2 dazu genommen also mit 6 NKS gerechnet. Damit ist man zumindest im Börsenumfeld sauber. Würde ich Zinsberechnung machen hätte ich vielleicht noch mehr genommen.
Aber warum? Sind die Preise so genau? Wie bezahlst du 42,123456 Euro an jemanden? Der Punkt ist ja auch, dass man manchmal gezwungen ist zu runden, weil es bestimmte Summen in der Realität gar nicht gibt.
-
@wob
Wenn du Dinge rechnest die in der Buchhaltung eines Unternehmen landen, dann gibt es genaue Vorschriften wo mit wie viel Genauigkeit zu rechnen ist, wo und wie genau gerundet werden muss etc. Da ist an vielen Stellen sub-Cent Genauigkeit vorgeschrieben.Also Beispielsweise wenn du 100 Artikel um 1 Cent verkaufst, dann musst du ja Steuer zahlen. Wenn du jetzt 100 mal die Steuer für 1 Cent berechnest und das aufaddierst, brauchst du mehr Genauigkeit als nur 1 Cent damit da was vernünftiges rauskommt.
Ähnliche Fälle kann es auch geben wenn man bloss intern rumrechnet, ohne gesetzliche Auflagen.
Wie bezahlst du 42,123456 Euro an jemanden?
Wie bezahl ich 0,891 Euro an jemanden? Trotzdem werden Spritpreise mit 3 NKS angegeben und gerechnet. Für den finalen Preis wird dann auf 2 NKS gerundet. Aber wenn du 10 Liter kaufst zahlst du eben 8,91 Euro und nicht 8,90.
