Round gibt unterschiedliche Nachkommastellen zurück

[DanielJ]

Zitat von messie:

as erklärt mir zwar noch nicht, warum das Round doch das Rundungsgeraffel liefert aber für den Alltagsgebrauch ist das ok

Das Round liefert dir exakte 0.3, aber das Speichern in einem Float macht es wieder zu nichte. Wie gesagt, ein Float kann nicht jeden Wert exakt repräsentieren - das ist auch der Grund warum Delphi dir CompareValue und SameValue anbietet.
Willst du exakte Dezimalwerte, brauchst du ein Festkommaformat.

Wissenschafliche Abhandlung zu dem Thema Klick

Dies sollte man zumindest in Grundzügen verstehen, sonst verzapft man schnell einige Bugs!

[himitsu]

Bezüglich des Currency in Delphi ist die Erklärung auch ganz einfach.

Currency ist in Wirklichkeit ein Int64, bei welchem die understen 4 Dezinalstellen als Nachkommastellen angesehn werden ( i / 1000 ),
womit es innerhalb aller Dezimalstellen keine Rundungsfehler geben kann.

Darum nennt sich das auch Currency aka "Währung", weil gerade dort besser nicht falsch gerechnet werden sollte.

[DanielJ]

Zitat von himitsu:

Darum nennt sich das auch Currency aka "Währung", weil gerade dort besser nicht falsch gerechnet werden sollte.

Das ist auch nur Begrenzt richtig: Currency ist halt, wenn man mit dem Ergebnis noch weiterrechnen will, unglaublich ungenau. Das kann, gerade wenn´s um´s Geld geht, auch Fatal sein!
Man sollte sich also gut überlegen wo man welche Genauigkeit braucht.
Es hat einen Grund warum es beide Datentypen gibt.

[himitsu]

Wieso ungenau?

Es ist auf die definierten 4 Nachkommastellen zu 100% ganz genau.

[ibp]

Zitat von himitsu:

Wieso ungenau?

Es ist auf die definierten 4 Nachkommastellen zu 100% ganz genau.

ich könnte mir vorstellen, dass bei der Finanzmathematik durchaus mehr stellen relevant sein könnten. Gerade für Banken mit tausenden Transaktionen könnte eine Beschränkung auf 4 NK-Stellen sehr schnell ein größerer Verlust bedeuten.

[DanielJ]

Zitat von himitsu:

Wieso ungenau?

du gibst dir im nächsten Satz die Antwort ja schon selber:

Zitat von himitsu:

Es ist auf die definierten 4 Nachkommastellen

die Genaugikeit bei z.b. € beträgt damit ein Hundertstel Cent.
Wenn ich Jezt Heizölhändler bin und sagen wir von meinem Großhändler Öl Kaufe für 0,63145 € / Liter.
Ich ordere also 100.000 Liter ... wieviel Kostet das dann?
63.145 € oder 63.140 €?
Wer zahlt meinem Großhändler die Fehlenden 5 €?
Du der du mir das Programm Programmiert hast?

[p80286]

Na dann arbeite ich eben mit 6 Nachkommastellen, oder dem BCD-Format.
Wenn ich mich richtig erinnere, konnte Cobol vor 40 Jahren schon mit 8 Nachkommastellen umgehen.
Man braucht eben für jede Arbeit das richtige Werkzeug.

Gruß
K-H

[BUG]

Zitat von DanielJ:

Wer zahlt meinem Großhändler die Fehlenden 5 €?
Du der du mir das Programm Programmiert hast?

Wenn es solche Anforderungen gibt, muss man das vorher wissen.

Man sollte die Lösung halt nach Problem auswählen:

• Gleitkommazahlen (Abstand der darstellbaren Zahlen ist abhängig von Absolutbetrag)
• Fixkommazahlen (Abstand der darstellbaren Zahlen über ganzen Wertebereich gleich)
• Bruchrechnung (mit beliebiger Genauigkeit für Addition/Subtraktion/Multiplikation/Division)
• Symbolisches Rechnen (mit beliebiger Genauigkeit)

Fixkommazahlen neigen halt nicht so zur Instabilität wie Gleitkommazahlen (zB. keine Auslöschung + Assoziativität) und man kann die Genauigkeit besser abschätzen.
Trotzdem kann man relativ schnell mit ihnen Rechnen. Für Standardaufgaben ist das wohl einfach der beste Kompromiss.

Ich könnte mir auch vorstellen, dass Rechnen mit rationalen Zahlen / Brüchen (mit beliebig großem Zähler/Nenner) viele Sonderfälle abdecken wird, wenn man nur Buchhaltung macht.

Zitat von ibp:

Gerade für Banken mit tausenden Transaktionen könnte eine Beschränkung auf 4 NK-Stellen sehr schnell ein größerer Verlust bedeuten.

Ich würde meinen, Banken führen nur Transaktionen mit vorgegebener Genauigkeit aus.
Wie im Zweifelsfall (zB. beim Zins oder bei Transaktionsgebühren) gerundet wird, ist sehr wahrscheinlich genau in Verträgen festgehalten.

[Sir Rufo]

Zitat von DanielJ:

Zitat von himitsu:

Wieso ungenau?

du gibst dir im nächsten Satz die Antwort ja schon selber:

Zitat von himitsu:

Es ist auf die definierten 4 Nachkommastellen

die Genaugikeit bei z.b. € beträgt damit ein Hundertstel Cent.
Wenn ich Jezt Heizölhändler bin und sagen wir von meinem Großhändler Öl Kaufe für 0,63145 € / Liter.
Ich ordere also 100.000 Liter ... wieviel Kostet das dann?
63.145 € oder 63.140 €?
Wer zahlt meinem Großhändler die Fehlenden 5 €?
Du der du mir das Programm Programmiert hast?

Und wenn ich 100 Liter kaufe, dann steht auf der Rechnung 63,145€?
Wie soll ich das bezahlen, oder wie soll der das rausgeben? Indem er einen Cent durchschneidet?

Irgendwann muss gerundet werden, spätestens beim Berechnen des Rechnungsbetrages, denn dort können nur ganze Cent stehen.
Zudem gibt es fast jede WaWi her mengenabhängige Preise zu hinterlegen (und die sind idR bei größeren Mengen günstiger). Bei deinem Beispiel wären es dann z.B. 631,45€/100l und schon sind wieder alle glücklich.

[Furtbichler]

Das Problem des Rundens tritt naturgegebenermaßen auch in der Finanzwelt auf. Es werden Zinsen, Steuern erhoben, Rabatte gewährt und in andere Währungen umgerechnet.

Da man nicht mit unendlich vielen Stellen rechnen kann, muss also gerundet werden. Wird nur aufgerundet, stimmt die Balance nicht. Wird nur abgerundet auch nicht. Also wurde das bankers rounding erfunden, das mal ab- und mal aufrundet (50:50). Unterm Strich gleicht sich das aus.

Die vier Stellen in der Finanzwelt sind meines erachtens nach dazu da, um bei mathematischen Umrechnungen im 1. oder 2. Schritt das Bankersrounding hinter den Kulissen, also in 4. Stelle ablaufen zu lassen.

Das Finanzamt gibt im Übrigen bei der Berechnung des Bruttobetrages genaue Vorgaben. Auch lustig: Bei 1/10tel Cent sind sie pingelig, aber wenn es um Steuerbetrug in Milliardenhöhe geht, schauen sie nicht so genau hin und würden sich mit einer Flatrate begnügen.