nicht angemeldet
Ach, und das soll hinsichtlich der Ungenauigkeit bei der Darstellung von Dezimalbrüchen in binär arbeitenden Systemen besser werden, wenn man stattdessen in Euro rechnet, und damit das Komma noch um zwei Stellen nach links verschiebt …?
Du glaubst also, wenn ich ein 32-Bit float habe macht sich ein Rundungsfehler
bemerkbar? Das würde ja bedeuten, dass die Finanzämter weltweit Systeme anerkennen, die völlig ungenau sind und damit nicht brauchbar.
ES gibt IMO einen Unterschied zwischen Theorie und Praxis. Und die Praxis zeigt, dass diese Rundungsfehler nicht relevant sind.
Die „das haben wir schon immer so gemacht“- und „das machen die anderen auch so“-Argumentation überzeugt mich an dieser Stelle eher weniger.
Liegt vermutlich daran, dass es keine solche Argbumentation ist. Hier geht es um Kompatibilität der verschiedenen Systeme um per POS auf ein ERP eines anderen Anbieters aufbauen zu können ohne jeden Furz konvertieren zu müssen (wobei hier wieder Rundungsfehler entstehen die nicht auftreten, wenn der Wert unverändert übernommen wird)
Du kannst mir aber gerne ein _praxistaugliches_ Beispiel nennen, bei dem ein Rundungsfehler relevant ist. Und das Beispiel mit 42.001 ist hier nicht interessant, weil, wie geschrieben, oft 4 und mehr stellen hinter dem Komma interessant sind. Praxistauglich ist ein Beispiel also erst dann, wenn Beträge im 1/1000-Cent Bereich so verfälscht werden, dass sie nicht mehr brauchbar sind.
Der Martin
Gunnar Bittersmann