kaufmännisch runden

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

[arnof]

@JasonDX: hat Du hier die Frage gestellt ?

Wenn Du einen Sinnvollen Beitrag hast, dann schreibe Ihn. Wenn Du meinst, das mein Beitrag falsch ist, dann hoffe ich für deine Kunden, das Du nichts mit WAWIS/ERP-System usw in der Entwicklung zu tun hast!

[JasonDX]

Zitat von arnof:

@JasonDX: hat Du hier die Frage gestellt ?

Wenn Du einen Sinnvollen Beitrag hast, dann schreibe Ihn.

Ich habe den Thread nicht begonnen, aber es haben sich im Verlauf Fragen für mich aufgetan, die die von dir vorgeschlagene Lösung betreffen. Die erste Frage war die: Was passiert, wenn einer der nicht vorgesehenen edge-cases auftritt? Die Frage baut auf der Beobachtung auf, dass der Lösungsvorschlag nicht alle Fälle korrekt behandelt.
Die zweite Frage im Beitrag war die was passiert, wenn eine Lösung verwendet wird, welche alle Fälle korrekt abdeckt. Ich bin noch keine 25 Jahre dabei, insofern ist es durchaus interessant zu wissen, wieso eine Lösung der anderen vorgezogen wird.

[arnof]

Jeder muss wissen wie er es löst, den Gedanken was dazuzurechnen ist erstmal ungewöhnlich und macht sicher auf den ersten Blick komisch und mag falsch erscheinen. Andere Datentypen zu nehmen ist sicher auch eine Lösung, ich möchte mich aber nicht nur auf EMBA verlassen, manchmal ist man da halt auch verlassen

Ich kann nur aus meiner Erfahrung sagen, da ich mich in meinen Programmiererleben sicher viele Monate damit beschäftigt habe.

Vor dem runden einfach 0.000000000001 oder sowas in der Art addieren, dann klapp es auch mit dem Runden auf 2 Stellen

[Billa]

Hallo,

habe normalerweise nicht viel mit Fließkommaoperationen zu tun, aber vor Jahren einen Code aus der Computersteinzeit (COBOL) gesehen. Dort wurden für Beträge erstmal grundsätzlich nur ganze Zahlen gespeichert, also z.B. Beträge in Cent. Bei jeglicher Prozentrechnung oder Division wurde dem Ergebnis 0.5 hinzuaddiert und dann der Nachkommaanteil einfach abgeschnitten. Hat wohl zufriedenstellend funktioniert (stammte angeblich aus der Versicherungsbranche). Den Code habe ich leider nicht mehr, erinnere mich aber noch gut an diese seltsame Methode ... hth

[Morphie]

Weil es im weitesten Sinne zum Thema passt: http://javathreads.de/2009/03/niemal...ege-berechnen/

[Mikkey]

@billa:
Das von Dir beschriebene Verfahren ist nicht ungewöhnlich, in COBOL gibt es aber die Ergänzung "ROUNDED" für Multiplikationen, Divisionen und "Computations", die so etwas automatisch erledigen. Die Rundung nach ähnlicher Methode habe ich selbst in kaufmännischen Anwendungen selbst schon in C++ und in Assembler benutzt.

@arnof, JasonDX:
Rechnungen mit Fließkommazahlen sind nunmal ungenau und deshalb generell nicht für kaufmännische Zwecke geeignet. Das Addieren von einem noch so kleinen "epsilon" ist und bleibt ein Hack. Wenn einem kein "Dezimal"-Datentyp zur Verfügung steht, ist es besser, bei COBOL abzugucken und alle Rechnungen mit Ganzzahlarithmetik durchzuführen - die ist nämlich genau und man hat Rundungsvorgänge selbst in der Hand.

[BUG]

Wie man wo rundet, ist vermutlich auch anwendungsspezifisch.
Bei durch Menschen nachvollziehenden Rechnungen, kann ich mir gut vorstellen, dass das Runden nach jeder Operation (Zinsen berechnen) passiert und das Auf-/Abrunden durch Verträge geregelt ist.
Wenn ein komplexes Modell eine bestimmten Erwartungswert für die interne Verwendung ausspucken soll, wird vielleicht nur am Ende gerundet.

Das Runden durch Addieren von 5 auf der ersten nicht-signifikanten Stelle finde ich nicht so ungewöhnlich. Im Grunde realisiert man damit das normale Runden auf eine bestimmte Stelle ohne irgendwelche Sprünge.