kaufmännisch runden

[sx2008]

siehe Code-Library: http://www.delphipraxis.net/46397-cu...ch-runden.html

[himitsu]

Zitat von sx2008:

siehe Code-Library: http://www.delphipraxis.net/46397-cu...ch-runden.html

Ich kann mich täuschen, aber für mich sieht das eher wie mathematisches Runden aus und nicht wie das Kaufmännische.

[Morphie]

Zitat von Uwe Raabe:

Vielleicht will Morphie damit aber auch nur sagen, daß für kaufmännische Anwendungsfälle der Datentyp Currency die bessere Wahl ist?

Genau so ist es

[Furtbichler]

Allgemein wird in der praktischen Anwendung technisch-wissenschaftlicher Auswertung mit Augenmaß hantiert. Das bedeutet, das 3-4 (seltener 5) signifikante Stellen als vollkommen ausreichend erachtet werden, um Kenngrößen darzustellen. 3-4 Stellen bedeutet eine Genauigkeit von 2% - 0.2%. Und das entspricht im wahrsten Sinne des Wortes dem maximal möglichen Augenmaß.

Currency kann hier geeignet sein, muß aber nicht (wegen der festen 4 Nachkommastellen). Man kann schon mit Double/Extended arbeiten und die Ungenauigkeiten des Datentyps in Kauf nehmen, denn diese bewegen sich i.A. weit jenseits der geforderten Darstellungsgenauigkeit. Sofern man also keine aufwändigen Iterationen betreibt oder sich in der Atomphysik tummelt (wo mit sehr großen und sehr kleinen Zahlen hantiert wird), kann man sich auf Double verlassen. Iterationen würden die Rundungsungenauigkeiten 'nach links verschieben' und beim Rechnen mit sehr großen und (absolut) sehr kleinen Zahlen passiert das Gleiche.

Man muss nur wissen, das Vergleichsoperationen immer im Kontext der Genauigkeit durchgeführt werden müssen, in der man sich gerade befindet.

Bei Geldbeträgen ist die geforderte Genauigkeit 1 Cent. Ergo werde ich auf 2 Stellen nach dem Komma runden und Vergleiche so formulieren, das die Ungenauigkeit von 0.5 ct berücksichtigt wird. Also ist ein Wert 0.00$, wenn er kleiner als 0.005$ ist (absolut), und A>B genau dann, wenn A-B > 0.005 ct ist usw. Das reicht vollkommen aus.

Bei der Berechnung von Zinsen, Steuern usw. wird gemäß den Vorgaben des Finanzamts auf Centbeträge gerundet. Wenn nach dem Runden die o.g. Vergleichslogik angewandt wird, kann nichts passieren. Pfennigfuchser können noch den arnof-Trick verwenden, der zwar innerlich wehtut, aber genau die datentypbedingte Ungenauigkeit bedingt, mit der man (im Übrigen in allen Programmiersprachen, die Fließkommazahlen verwenden) leben muss.

Eine Alternative dazu ist der Datentyp 'Currency', der jedoch einen limitierten Wertebereich besitzt und fest vier Nachkommastellen hat. Dafür rechnet man damit punktgenau. Für jegliche Geldberechnungen sollte dieser Datentyp ausreichen, denn 50 Stellen reichen für sämtliches auf der Welt befindliche Geld, egal in welcher Währung.

Allgemein gesehen wäre der BCD-Datentyp hier ideal, aber soweit ich das sehe, existiert hier kein nativer Datentyp in Delphi (in C# existiert 'decimal'). Allerdings kann man sich mit Klassen behelfen, die mit beliebig großen Zahlen umgehen können.

[MrSpock]

Ich hatte vor einiger Zeit auch einen lästigen Rundungsfehler und das hat mir geholfen.

[arnof]

Egal welche Datentypen man verwendet oder das benutzte System bietet, wenn man eine Kleinigkeit hinzuaddiert, so bekommt man das Floatproblem in den Griff.

Zur Info für die Allgemeinheit: alle Floattypen sind nur Näherungswerte und aus 0.015 (was gerundet dann 0.02 währe kann schon mal im echten Leben folgendes werden:

0.014999999 was gerundet nun mal 0.01 ergibt.

Das ist schon großen Firmen passiert

[rapante]

Vielen Dank an alle die Licht ins Dunkel gebracht haben!
Ich habe mich jetzt erstmal für die Lösung von MrSpock entschieden.

Merke: 1 ist nicht immer gleich 1

[JasonDX]

Zitat von arnof:

Egal welche Datentypen man verwendet oder das benutzte System bietet, wenn man eine Kleinigkeit hinzuaddiert, so bekommt man das Floatproblem in den Griff.

Besser gesagt: man kann damit das Problem an einen anderen Ort verschieben, von dem man dann hofft, dass man dort nie vorbeikommt.
Ja, wenn 0.015 rauskommen sollte, das aber durch 0.01499999 approximiert wird, dann passt die Lösung mit +epsilon. Was aber wenn das Ergebnis der Rechnung 0.01499999 ist? Dann wird das Ergebnis verfälscht, weil auf 0.02 gerundet wird, obwohl 0.01 korrekt wäre.
Egal unter welchen Umständen man Gleitkommazahlen verwendet, es wird immer Probleme geben wenn man genaue Kommastellen braucht. Die einzige Lösung ist, einen für das Problem passenden Datentyp zu verwenden. (Siehe auch Furtbichlers Antwort)

[arnof]

Zitat von JasonDX:

Zitat von arnof:

Egal welche Datentypen man verwendet oder das benutzte System bietet, wenn man eine Kleinigkeit hinzuaddiert, so bekommt man das Floatproblem in den Griff.

Besser gesagt: man kann damit das Problem an einen anderen Ort verschieben, von dem man dann hofft, dass man dort nie vorbeikommt.
Ja, wenn 0.015 rauskommen sollte, das aber durch 0.01499999 approximiert wird, dann passt die Lösung mit +epsilon. Was aber wenn das Ergebnis der Rechnung 0.01499999 ist? Dann wird das Ergebnis verfälscht, weil auf 0.02 gerundet wird, obwohl 0.01 korrekt wäre.
Egal unter welchen Umständen man Gleitkommazahlen verwendet, es wird immer Probleme geben wenn man genaue Kommastellen braucht. Die einzige Lösung ist, einen für das Problem passenden Datentyp zu verwenden. (Siehe auch Furtbichlers Antwort)

Also ich habe noch keine Rechnung mit 0.01499999 gesehen. Ich mache das schon 25 Jahre und weiß wovon ich spreche. Man kann diesen Tipp annehmen oder auch nicht! Wenn man das nicht so macht, so kann ich Dir versprechend, das in bestimmten Branchen Dir die Software um die Ohren fliegt, wenn der Kunde anfängt nachzurechnen!

Natürlich ist die große Kunst nur an den richtigen Stellen zu runden, den gerundete Werte sind falsche Werte

[JasonDX]

Zitat von arnof:

Also ich habe noch keine Rechnung mit 0.01499999 gesehen. Ich mache das schon 25 Jahre und weiß wovon ich spreche.

Deswegen auch

Zitat von JasonDX:

man kann damit das Problem an einen anderen Ort verschieben, von dem man dann hofft, dass man dort nie vorbeikommt.

Du bist eben noch nie daran vorbeigekommen, und hoffst, dass dem so bleibt.

Zitat von arnof:

Wenn man das nicht so macht, so kann ich Dir versprechend, das in bestimmten Branchen Dir die Software um die Ohren fliegt, wenn der Kunde anfängt nachzurechnen!

Und was passiert, wenn der Kunde anfängt mit Rechnungen zu arbeiten, die 0.014999 als korrektes Ergebnis haben? Und wieso würde einem die Software um die Ohren fliegen, wenn sie korrekt rechnet? - also 0.015 rauskommt, wenn 0.015 rauskommen soll?
Ein +epsilon beim Runden eliminiert nicht die Ursache des Problems, sondern deckt nur die Symptome in den häufigsten Fällen ab.

Zitat von arnof:

Natürlich ist die große Kunst nur an den richtigen Stellen zu runden

Das auf jeden Fall.