Rundungsfehler ?

[indianer-frank]

Na, das ist doch schon mal ein Fortschritt.

Ich denke, wenn Du meine Ausführungen nachliest, habe ich nichts mM offensichtlich Fehlerhaftes behauptet. Das manche Fließkommaoperation nicht exakt sind (und das ist was anderes als korekt gerundet), ist eine Binsenweisheit. Aber es gibt Methoden und Algorithmen um halbwegs stabil solche Problem zu lösen (nennt sich Numerische Mathematik oder neudeutsch 'Scientific computing') und es gibt seit meht als 50 Jahren ausführliche Literatur dazu, und nicht nur Wikipedia.

Und jetzt endgültig Gute Nacht.

[Warf]

Stimmt hab an die Numerik gar nicht gedacht. Da sollte man natürlich wissen wie die Sprache rundet. Aber das ist ja alles wohldefiniert und ich glaube nicht das der große Teil der Pascal Entwickler selbst solche Algorithmen entwickeln. Beschweren kann man sich da nicht

[Mathias]

"Somit hat dieses Bank-Runden durchaus seine Richtigkeit/Sinn. Es ist um einiges gerechter."

Anscheinend ist die Kohle wieder mal wichtiger als die mathematische Genauigkeit.
In der Schule hatten wir mal, alles was grösser als x.5 ist, wird aufgerundet.

Dann tut es mir Leid um deine Lehrer; diese hätten später beibringen sollen, dass man auch anders runden kann.

Dies war noch in der Grundschule, und da gab es noch keine PCs.

[Mathias]

Ich habe mal ein wenig das Wiki angepasst, so das jedermann das Runden sieht.

http://wiki.freepascal.org/Round/de

[mschnell]

Dies war noch in der Grundschule, und da gab es noch keine PCs.

Bei Software ist es grundsätzlich verboten, sich auf den genauen Wert einer Real-Zahl zu verlassen. Realzahlen sind nur im Rahmen einer Genauigkeit (also +/- x%) verlässlich. Wenn die Zahl also z.B. 0.5 ist, muss man sie als irgendwo zwischen 0.5+% und 0.5-x% ansehen. Demzufolge ist die Rundung für den Programmierer grundsätzlich nicht vorhersehbar. Jedes Verhalten der Software ist absolut zulässig.

Dasselbe gilt natürlich auch für alle Real -> Integer Wandlung von Werten in der Nähe von ganzen Zahlen. Obwohl hier vermutlich sicher gestellt ist, dass bei nur gewandelten Werten, die nicht durch eine Berechnung gehen, die Rück-Wandlung das von Dummies erwartete Ergebnis liefert

Code: Alles auswählen

r: real; 
i: integer;
 
i := 1;
r := i;
i := r;  // nicht runden, sondern Abschneiden !
 
i := 1;
r := i;
r := r / 3.0;
r := r * 3.0;
i := r;  // Das Ergebnis ist nicht verlässlich
 
 

-Michael

[mschnell]

Ich habe mal ein wenig das Wiki angepasst, so das jedermann das Runden sieht.

Absolut korrekter und wichtiger Hinweis für Ignoranten, die nicht wissen, wie man mit Real-Werten umgehen muss.
Ich habe den Eintrag mal technisch ergänzt und emotional gerade gerückt.
-Michael

[wp_xyz]

Demzufolge ist die Rundung für den Programmierer grundsätzlich nicht vorhersehbar.

Nur wenn das Ergebnis in der Nähe von x.5 liegt.

Code: Alles auswählen

r: real; 
i: integer;
 
i := 1;
r := i;
i := r;  // nicht runden, sondern Abschneiden !
 
i := 1;
r := i;
r := r / 3.0;
r := r * 3.0;
i := r;  // Das Ergebnis ist nicht verlässlich  

Versteh ich nicht.

Warum muss ich, wenn das Ergebnis nahe einer ganzen Zahl liegen muss, trunc() aufrufen statt round()? Bei dem Beispiel liefert Round immer das richtige Ergebnis, Trunc is nicht verlässlich, z.B. falls r als 2.99999999999999999532341 rauskommt. Nur wenn das Ergebnis x.5 erwartet wird, muss man - ggfs. neben dem BankersRouding - noch bedenken, dass das x.5 auch als x.499999999999 ausfallen kann - dann rundet Round in die falsche Richtung. Aber ehrlich gesagt, wenn das eine Rolle spielt, dann muss man halt eine Dezimalstelle mehr anzeigen.

Generell sollte man nur runden, wenn das Endergebnis einer Rechnung angezeigt werden soll. Problematisch ist es, wenn Rechen-Ergebnisse gerundet in Edit Controls etc. gespeichert und von dort in weiteren Rechnungen weiterverwendet werden.

[Socke]

Ich habe den Eintrag mal technisch ergänzt und emotional gerade gerückt.

Wo wir gerade beim Wiki sind: ich habe die Information zu SetRoundingMode eingefügt.

[wp_xyz]

Wo wir gerade beim Wiki sind: ich habe die Information zu SetRoundingMode eingefügt.

Und ich habe mir erlaubt, die Details etwas auszuführen - die offizielle Doku, auf die du verlinkst, ist wie immer sehr karg.

[indianer-frank]

Ich habe mal ein wenig das Wiki angepasst, so das jedermann das Runden sieht.
http://wiki.freepascal.org/Round/de

Ist noch ein kleiner Fehler drin: 12.5 wird auch 12 gerundet nicht auf 1.

Ich habe den Eintrag mal technisch ergänzt und emotional gerade gerückt.

Wo wir gerade beim Wiki sind: ich habe die Information zu SetRoundingMode eingefügt.

Leider ist der Eintrag unter http://lazarus-ccr.sourceforge.net/docs ... gmode.html ziemlich falsch. Es wird natürlich nicht auf das nächste Integer gerundet sondern auf die nächste darstellbare Fließkommazahl, man beachte dieses Runden wird bei jeder Operation angewendet, es wäre ja schlimm, wenn 10+Pi = 13 wäre. Was in dem Link beschrieben wird, ist die nur Auswirkung auf die Funktion round. Die Delphi6-Hilfe ist genauer

Code: Alles auswählen

 
rmNearest    Rounds to the closest value.
rmDown       Rounds toward negative infinity.
rmUp	      Rounds toward positive infinity.
rmTruncate   Truncates the value, rounding positive numbers down and negative numbers up.
 

[Socke]

Leider ist der Eintrag unter http://lazarus-ccr.sourceforge.net/docs ... gmode.html ziemlich falsch. Es wird natürlich nicht auf das nächste Integer gerundet sondern auf die nächste darstellbare Fließkommazahl, man beachte dieses Runden wird bei jeder Operation angewendet, es wäre ja schlimm, wenn 10+Pi = 13 wäre. Was in dem Link beschrieben wird, ist die nur Auswirkung auf die Funktion round.

Kannst du hierzu bitte einen Bug-Eintrag erstellen? Am besten fügst du einen besseren, selbstgeschriebenen Text direkt bei.

[Socke]

Ich habe mal ein wenig das Wiki angepasst, so das jedermann das Runden sieht.
http://wiki.freepascal.org/Round/de

Ist noch ein kleiner Fehler drin: 12.5 wird auch 12 gerundet nicht auf 1.

Ist korrigiert; auch habe ich die Variablen im Beispiel-Code angepasst.

[indianer-frank]

Leider ist der Eintrag unter http://lazarus-ccr.sourceforge.net/docs ... gmode.html ziemlich falsch. Es wird natürlich nicht auf das nächste Integer gerundet sondern auf die nächste darstellbare Fließkommazahl, man beachte dieses Runden wird bei jeder Operation angewendet, es wäre ja schlimm, wenn 10+Pi = 13 wäre. Was in dem Link beschrieben wird, ist die nur Auswirkung auf die Funktion round.

Kannst du hierzu bitte einen Bug-Eintrag erstellen? Am besten fügst du einen besseren, selbstgeschriebenen Text direkt bei.

Mach ich nach der Mittagspause.

Edit: Fertig, siehe https://bugs.freepascal.org/view.php?id=33805

[mschnell]

Nur wenn das Ergebnis in der Nähe von x.5 liegt.

Na klar.

Warum muss ich, wenn das Ergebnis nahe einer ganzen Zahl liegen muss, trunc() aufrufen statt round()

Der Kommentar soll bedeuten, dass bei einer Zuweisung real-> integer der Compiler nicht Round(), sondern Trunc() einbaut.

-Michael

[mschnell]

Und ich habe mir erlaubt, die Details etwas auszuführen - die offizielle Doku, auf die du verlinkst, ist wie immer sehr karg.

Super ! SetRoundMode(ARoundMode) kannte ich noch nicht.
-Michael