Round gibt unterschiedliche Nachkommastellen zurück

[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:

Zitat von DanielJ (Beitrag 1192251)

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:

Zitat von ibp (Beitrag 1192249)

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.

[Medium]

Zitat:

Zitat von messie (Beitrag 1192247)

Ich glaube, da ist der Weg zur nächsten Frage: wo stehen meine Daten aus dem View genau? Werden die irgendwo zwischengespeichert oder hortet meine Query nur einen Pointer auf das Ergebnis?

Die Frage kann ich zwar nicht beantworten, da aber eine Fülle von DBMS existieren, die über eine noch größere Menge von Treibern und Schichten angesprochen werden, die teilweise auch gerne mal aneinandergereiht werden, deren genauste Interna man alle kennen und berücksichtigen müsste, ist diese Frage auch nicht wirklich beantwortungswürdig:

- Runden im SQL macht man, wenn man im SQL selbst mit den Werten rechnen will

- Will man Werte gerundet darstellen, rundet man nur zum Zwecke der Darstellung ganz genau zum Zeitpunkt der Umwandlung in die Darstellung (üblicherweise einen String)

Welches Zahlenformat sich für eine Aufgabe am besten eigent, ist von obigem völlig losgelöst, und hängt nur vom Einsatzzweck ab, niemals von einer gewünschten Darstellung.

[Sir Rufo]

Zitat:

Zitat von DanielJ (Beitrag 1192251)

Zitat:

Zitat von himitsu (Beitrag 1192233)

Wieso ungenau?

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

Zitat:

Zitat von himitsu (Beitrag 1192233)

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.

[DanielJ]

Zitat:

Zitat von Sir Rufo (Beitrag 1192285)

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.

Du hast wohl noch nie getankt was?

Klar, wird am ende gerundet, dann kannst du aber auch nur max einen halben Cent verlieren oder gewinnen.
Das war auch nur eine Beispiel da himitsu mein Aussage das die Genauigkeit (von 1/10.000) schnell zu gering wird scheinbar vorher nicht verstanden hatte.
Rechnet man selbiges Beispiel mit einem Double hat man kein relevantes Genauigkeitsproblem!