Genauigkeit von String to Single Konvertierung

[himitsu]

und dennoch ist alles falsch, denn im Bankenwesen speichert keine Bank massenhaft Nachkommastellen.

4-6 Dezimalstellen und beim Ein-/Auszahlen nur die "normalen" 2 Dezimalstellen.
Wenn man hier also "normal" nach den jeweiligen Iterationen rundet, dann ist es fast egal, welchen Typ man hier verwendet.

Egal was ihr anstellt, es ist unmöglich 1.7182818… € oder was auch immer einzuzahlen.


Diese Berechnung als Beispiel für grundsätzlichen Rundungsprobleme OK, aber mit dem Beispiel an einem Konto ist absolut abwägig.

[Jost Riedel]

Natürlich nicht. Geld, egal welche Währung, sind Integer. Die Unterteilung in Euro und Cent ist Augenwischerei - Euro ist nur eine Bezeichnung für einhundert Cent. Genauso, wie hundert ein anderes Wort für einhundert ist.

Addieren und subtrahieren kann man Geldbeträge mit Integers und einem impliziten Dezimalpunkt (Sorry, Komma). Und wenn man noch Multiplizieren und Dividieren will wie die Banken, dann braucht man 4 implizite Nachkommastellen - so wie z.B. beim Delphi Typ Currency.

Die BCD Darstellung macht nichts wirklich genauer - nur anders. Und BCD stellt nur die Mantisse anders dar. Eigentlich gar nicht erforderlich. Der Exponent und implizierte Basis geben den Takt an - die Mantisse ist nur ein Integer. Aber wenn die implizierte Basis 2 ist, dann ist ein Teilen oder Multiplizieren mit dieser Basis (und das ist ist eine sehr häufige Operation) bei einer binär codierten Mantisse ein simples Shiften. Oder bei einer Basis 10 und einer BCD codierten Mantisse ebenfalls.

Fließkommazahlen haben immer eine recht konstante relative Genauigkeit. Und finanzielle Berechnungen eine absolute (auf einen Pfennig, oder Cent, genaue), und die kann bei kleinen Beträgen relativ schlecht sein.

32 bit floating point braucht man im Prinzip nur für eine Sache: Um die selben spaßig schlechten Ergebnisse zu erhalten wie uralte FORTRAN Programme.

[p80286]

Andreas13 hat es doch schön ausgeführt, wenn man sich blind auf ein Programm verläßt kann man verlassen sein.
Nachdem ich vor ein paar Jahren "unerklärliche Rundungsfehler" hatte, war klar, das Single oder Double selbst für dreistellige Beträge mit relativ einfachen Prozentbrüchen nicht geeignet ist. Aber es gibt ja Currency.
Bleib die Frage warum diese Krüppeltypen überhaupt existieren, wenn die Genauigkeit auf dem Stand eines Rechenschiebers stehen geblieben ist.

Gruß
K-H

[himitsu]

Wenn dir was Besseres einfällt, dann darfst es gern patentieren und reich werden.

Es sind halt Typen, die vielen Ansprüchen gerecht werden müssen
und aufgrund der Größe geht es nicht ohne Kompromisse.

[Redeemer]

Dezimale Gleitkommazahlen. Im Prinzip die beiden Komponenten einer in Wissenschaftlicher Notation aufgeschriebener Zahl hintereinander als Integers gespeichert (Exponent ggf. mit Bias statt vorzeichenbehaftetem Integer), nur wäre die Mantisse wohl sinnvollerweise nicht normiert. Der Exponent ist zur Basis 10 zu verstehen und kann deshalb um 2 bis 3 Bits (=lb(10)) gekürzt werden.

Zitat:

Zitat von Andreas13 (Beitrag 1462293)

Darüber hinaus hast Du gemogelt, weil Du nicht einmal Deine eigene Formel mit den verschiedenen Real-Typen berechnet hast, sondern nur Deine allerletzte Operation: 15511210043330985984000000 e - 26652630354867072870693626.

Nein.