rundungsfehler
-
hi,
in meinem Buch wird erwähnt, das float double und long double (besonders float) oft Rundungsfehler enthalten und man sie deshalb nie z.b. für eine Software einsetzten sollte, die mit wichtigen Geldbeträgen arbeitet. Man sollte lieber z.b. 1,99 Euro 1 und 99 als Integer darstellen. Stimmt das? Kommt mir etwas komisch vor
-
also genau sind die datentypen nicht
beispiel
ich hab bei nem programm 4.5 eigegeben (double) und rauskam 4.99999956
als ichw eiter gerehcnet hab ging das irgendwann wieder auf
aber kurz danach wars wieder ungenau was mein rpogramm dann auch letzt entlich zum absturz gebracht hat...also ne klasse für solche zahlen zu schreiben sit schon was besser...
-
Das Problem ist, dass mit der binären Schreibweise einige Dezimalzahlen nicht exakt angegeben werden können, deshalb entstehen bei Fliesskommazahlen immer Rundungsfehler. Normalerweise sind diese vernachlässigbar, aber gerade bei solchen Dingen wie Geldbeträge würde ich schon mit Integern rechnen. Zählvariabeln ist ein anderes Beispiel, wo sich Fliesskommazahlen negativ auswirken.
-
Nexus schrieb:
Das Problem ist, dass mit der binären Schreibweise einige Dezimalzahlen nicht exakt angegeben werden können
… zumindest nicht mit endlich vielen Stellen. Für die Dezimalschreibweise gilt aber dasselbe, 1/3 z.B. kann nicht als endlicher Dezimalbruch dargestellt werden.
(… nur als Klarstellung, dass das kein Problem der binären Darstellung ist sondern generell der Darstellung mit Kommastellen.)
-
TOBIAS400 schrieb:
Man sollte lieber z.b. 1,99 Euro 1 und 99 als Integer darstellen. Stimmt das? Kommt mir etwas komisch vor
Na ja, wenn die in der Bank mit 1,99 rechnen und dann Rundungsfehler
rauskommen würden!
-
D schrieb:
TOBIAS400 schrieb:
Man sollte lieber z.b. 1,99 Euro 1 und 99 als Integer darstellen. Stimmt das? Kommt mir etwas komisch vor
Na ja, wenn die in der Bank mit 1,99 rechnen und dann Rundungsfehler
rauskommen würden!Ich müsste noch ein wenig Geld ein/auszahlen gehen.. ^^ Mal eben ne Miliarde Transaktionen machen und schon ist man Multimilionär.. :p
-
Skym0sh0 schrieb:
ich hab bei nem programm 4.5 eigegeben (double) und rauskam 4.99999956
Abgesehen davon, dass das ein ziemlich gewaltiger Rundungsfehler wäre, kann das nicht sein. 4.5 ist nämlich exakt als double darstellbar.
-
drakon schrieb:
D schrieb:
TOBIAS400 schrieb:
Man sollte lieber z.b. 1,99 Euro 1 und 99 als Integer darstellen. Stimmt das? Kommt mir etwas komisch vor
Na ja, wenn die in der Bank mit 1,99 rechnen und dann Rundungsfehler
rauskommen würden!Ich müsste noch ein wenig Geld ein/auszahlen gehen.. ^^ Mal eben ne Miliarde Transaktionen machen und schon ist man Multimilionär.. :p
Es geht um's Prinzip!
-
D schrieb:
Es geht um's Prinzip!
Was willst du mir jetzt damit sagen?Wenn die in der Bank 1.99 auf 2 aufrunden würde, wäre ich ein glücklicher Kunde und mit ein paar (Millionen) Transaktionen wäre ich reich..
-
Bashar schrieb:
Skym0sh0 schrieb:
ich hab bei nem programm 4.5 eigegeben (double) und rauskam 4.99999956
Abgesehen davon, dass das ein ziemlich gewaltiger Rundungsfehler wäre, kann das nicht sein. 4.5 ist nämlich exakt als double darstellbar.
Er hat wahrscheinlich die eingebene Zahl mit 10/9 multipliziert und wieder ausgeben lassen...
Ausserdem: Wenn du eine Zahl eingibst, die so wenig Stellen hat, und mit ihr nichts machst, und sie dann wieder ausgeben lässt, kommt exakt die selbe Zahl heraus. Probleme gibts erst bei Berechnungen.
-
der genaue kontext fällt mir grad nicht ein
aber ich hab ne klasse für bruchzahlen geschrieben und einen dezimal wert (double) an den CTor gegeben und es gkam eine leichte änderung drin vor
5.3253 ---> 5.3253000000000004
in dem fall hat es mir das gesamte programm zerschossen
da ich die zahl auch immer wieder mit 10 multi und dividieren musste und es wurde ziemlich ungenau was sichd ann auch in einer endlos schleife bemerkbar gemacht hat....naja
-
Das kann aber eigentlich nicht sein, wenn du wirklich nur den Wert übergeben hast, ohne ihn zu ändern.
double a; cin >> a; cout << a;Hier wird immer das gleiche ausgegeben, wie du eingegeben hast (mal von der Ausgabegenauigkeit abgesehen). Und die Parameterübergabe sollte den Wert auch nicht manipulieren.
-
Skym0sh0 schrieb:
der genaue kontext fällt mir grad nicht ein
aber ich hab ne klasse für bruchzahlen geschrieben und einen dezimal wert (double) an den CTor gegeben und es gkam eine leichte änderung drin vor
5.3253 ---> 5.3253000000000004
in dem fall hat es mir das gesamte programm zerschossen
da ich die zahl auch immer wieder mit 10 multi und dividieren musste und es wurde ziemlich ungenau was sichd ann auch in einer endlos schleife bemerkbar gemacht hat....naja
Mit anderen Worten: du hast drauf los gecoded, ohne dir ein paar Gedanken darüber zu machen, was double darstellt.
Nebenbei: Rechendoperationen mit Gleitkommazahlen sind niemals ungenau - Ungenauigkeiten entstehen erst dadurch, dass das Ergebnis wieder als Gleitkommazahl dargestellt werden muss, und dies ist nicht immer exakt möglich.
Ein endlicher Binärbruch (und nur solche Zahlen sind exakt darstellbar) endet in Dazimaldarstellung stets mit der Ziffernfolge 25 oder 75 (wenn er wenigstens zwei Nachkommastellen hat - bei genau einer Nachkommastelle ist es stets die Fünf), umgekehrt kann eine Zahl, die wenigstens zwei Nachkommastellen hat und nicht auf 25 oder 75 endet, nicht exakt als Gleitkommazahl gespeichert werden. Es ist auf Anhieb völlig klar, dass
5.3253 nicht exakt gespeichert werden kann, aber auch 5.3253000000000004 ist nicht der exakte Wert. Das alles hat wenig speziell mit der Sprache zu tun.
-
Bei z.B. Geldbeträgen haben Gleikommazahlen nun einmal beliebig viele Nachkommastellen - je nach Darstellungsgenauigkeit. Man kann natürlich jederzeit auch runden über den kleinen Umweg einer Integerzahl oder man rechnet gleich mit solchen. Will heissen: mit Cents statt Euros.
-
Nexus schrieb:
Ausserdem: Wenn du eine Zahl eingibst, die so wenig Stellen hat, und mit ihr nichts machst, und sie dann wieder ausgeben lässt, kommt exakt die selbe Zahl heraus. Probleme gibts erst bei Berechnungen.
Aber nur, weil die Ausgabe rundet. Wie camper schon sagte, kann beispielsweise 4.4 gar nicht exakt als double dargestellt werden. Wenn du wieder 4.4 ausgegeben bekommst, ist das eigentlich falsch bzw. ungenau und nur zufällig wieder richtig.