Einzelnen Beitrag anzeigen

mensch72

Registriert seit: 6. Feb 2008
838 Beiträge
 
#25

AW: Genauigkeit von Datentypen

  Alt 26. Feb 2015, 21:47
Für Anwendungen im Börsenumfeld, wo es durchaus Kurse/Preise auf 8! Nachkommastellen genau gibt, wenn es was mit YEN oder in "1/128" gestuften US Werten zu tun hat...

Wir verwenden dafür einen eigenen 64Bit "FixComma" Datentyp mit 9! Nachkommastellen, welcher Summen und Differenzen absolut rundungsfehlerfrei in Int64 rechnet. Auch speichern wir in dieser Anwendung nur solche Ganzzahl-Int64-Zahlen in Files/Tabellen.

Das Grundprinzip ist simpel: alle Werte sind quasi mit 1'000'000'000 multipliziert und man schafft so alles bis +/- 9'223'372'036','854'775'808 in einem Int64 ganzzahlig unterzubringen.

- Da Delphi ja überladene Operatoren unterstützt, haben wir uns so unseren Eigenen Datentyp auch mit den passenden Funktionen versehen, damit wir ohne Genauigkeitsverlust durch Typumwandlungen auch direkt damit rechnen können und vergleichen können... 11mal -0,11 von 1,21 abgezogen ergibt da wirklich =0
- Per "AsString" als Read/Write Property haben wir auch quasi ein eigenes "FixCommaToStr" bzw. "StrToFixComma" gleich mit eingebaut
- für "Single", "Double" & "Extended" haben wir per eigener impliziter Typumwandlung gleich die passende Epsilon-Rundung eingebaut, um bei "krummen" Eingangswerten die eigentlich gemeinte Zahl zu bestimmen
- für 32Bit Delphi haben wir per Inline-ASM und Coprozessornutzung eine sehr schnelle 128Bit genaue Multiplikation/Division realisiert, weil man da jeweils ein um Faktor 1'000'000'000 falsches Resultat bekommt was sich nur mit 128Bit Ganzzahlgenauigkeit völlig rundungsfehlerfrei berechnen lässt

Der "Zauber" sind einige 100 Quelltextzeilen, aber wenn man sich daran gewöhnt hat mit Kommazahlen ganz normal zu rechnen und zu vergleichen, dann will man es nicht mehr missen.
Egal welche Programmiersprache, ohne eigene selbst geprüfte Routinen/Operationen für Kommazahlen und Datum/Zeit mag ich vor allem im Finanzbereich nicht mehr arbeiten.
Der vorhandene Currency-Type konnte uns nicht überzeugen. Standardlösungen für beliebig "große" Zahlen schieden wegen der Verarbeitungsgeschwindigkeit aus.
  Mit Zitat antworten Zitat