kaufmännisch runden

[Morphie]

Nur mal aus Interesse: gibt es einen plausiblen Anwendungsfall dafür, eine Fließkommazahl kaufmännisch zu runden? Mir fällt so spontan nämlich keiner ein...

[arnof]

Praxis: jede Rechnung, Angebot oder Kassenbon ….

[Uwe Raabe]

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

[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