Genauigkeit von Datentypen

[mm1256]

Zitat von himitsu:

Muss?
Currency = 4 Nachkommastellen

....oooops....sorry. Verwende Currency nie und hatte was von 2 Nachkommastellen in Erinnerung

[Sir Rufo]

Zitat von mm1256:

Zitat von himitsu:

Muss?
Currency = 4 Nachkommastellen

....oooops....sorry. Verwende Currency nie und hatte was von 2 Nachkommastellen in Erinnerung

Es gibt Länder/Währungen da hat es mehr als 2 Nachkomma-Stellen und die wären ja hübsch angeschmiert. Von daher gab es bei der Definition des Datentyps eine gewisse Weitsicht und man hat dort 4 Stellen vorgesehen.

[himitsu]

Andere brauchen mit ihrem Quarter nur eine viertel Nachkommastelle.

Und dann noch bissl zum Rechnen, Positionsweise MwSt. usw.

Knapp 9 Billiarden Euro, auf einen tausenstel Euro genau ... da hätte man ruhig noch für ein/zwei Nachkommastellen mehr Platz gehabt.

[Sir Rufo]

Zitat von himitsu:

Andere brauchen mit ihrem Quarter nur eine viertel Nachkommastelle.

Und dann noch bissl zum Rechnen, Positionsweise MwSt. usw.

Knapp 9 Billiarden Euro, auf einen tausenstel Euro genau ... da hätte man ruhig noch für ein/zwei Nachkommastellen mehr Platz gehabt.

Ich vermute mal, dass die Bedeutung des Datentyps Currency etwas verkannt/nicht erkannt wird.

Das ist ein Datentyp für eine Währungs-Buchung. Und ich kenne niemanden, der seine Buchhaltung auf Mikro-Cent führt. Während einer Berechnung eines Buchwertes da nimmt man diese Mikro-Cents mit, aber irgendwann kommt ein Buchwert heraus und der ist dann im EURO-Raum auf 2 Stellen nach dem Komma gerundet (ohne jetzt auf die speziellen Rundung-Arten eingehen zu wollen).

Bei einer Rechnung z.B. erfolgt die Festlegung des Buchwerts auf Positions-Ebene. Jede Position hat also einen festgelegten Buchwert und der ist dann vom Typ Currency .

Artikel	Preis	Menge	Berechneter-Wert	Buch-Wert
Gold	1214,15($/oz.tr.)	1(g)	1214,15($/oz.tr.) / 31,1034768(g/oz.tr.) * 1(g) = 39,035828946299663($)	39,04($)

[mensch72]

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.