Rechenfehler

[Sebtis]

Hallo.

Ich bin auf ein interessantes Problem gestoßen.

Gehen wir aus von folgender simpler Berechnung:

Delphi-Quellcode:

function Berechnung(start: Extended; ende: Integer): Extended;
var i: Integer;
    a: Extended;
begin
  a := start;
  for i:=1 to ende do
  begin
    a := a*1.55;
    a := floor(a);
  end;
  result := a;
end;

Funktioniert an sich ohne Fehlermeldung.

ABER!!!

Für den Startwert 3500 ergibt sich ab dem 13. Durchlauf in irgendeiner Art ein Fehler.
Denn Delphie liefert mir hierbei den Wert 1043025. Ein OpenOffice-Tabelle, die Schleife in C++ und sogar mein CASIO-Taschenrechner liefern mir hier den Wert 1043026. Dieser Fehler setzt sich dann logischerweise immer weiter fort.

Meine Überlegung war ja ein Rundungsfehler, aber
1. so wirklich viel zu runden gibts da ja nich ^^
und
2. sowohl bei kleineren als auch bei größeren Werten gibt es keine Probleme. Zum Beispiel liefert der Startwert 1000000(1 Million) auch nach dem 30. Durchlauf noch das korrekte Ergebnis.

Einzig andere Idee wäre, dass es am FloatToStrF liegt. Aber glauben tu ich das nich.

Ich bin mit meinem Latein am Ende. Weiß hier jemand was dazu?

Falls nötig: ich verwende Borland Delphi 2005 auf WindowsXP SP3.

[Medium]

Das haben wir fast wöchentlich hier ;). Rundungsfehler war schon der richtige Gedanke: Fließkommadarstellung in binär kann nicht alle endlich genauen Dezimalwerte darstellen, da sie z.T. in Binärform periodisch werden, und ab und an - gerade bei Iterativen Prozessen - macht sich doch irgendwann mal die begrenzte Genauigkeit bemerkbar. Bei dir allerdings triff das vermutlich deswegen eher selten auf, da du mit dem floor() immer wieder in relativ gut auflösbare Bereiche kommst, bei größeren Zahlen aber zunehmend enger.

[Sebtis]

Hmm...ja aber dann verstehe ich nicht, warum ein Startwert von 1mio nach 30 Durchläufen immernoch den richtigen Wert liefert. Da kann es sich doch nicht um Genauigkeitsgrenzen handeln? Oder verstehe ich da was falsch?

[Luckie]

Zufall. Eventuell kommt es bei 3500 zu einer sehr ungünstigen, ungenauen Binärdarstellung.

[Medium]

Es ist prakisch Glückssache ob und wann und wie oft man zwischendrin in eine der zwei Fallen tappt, und ein Startwert mitten drin kann durchaus ungünstigere Folgen liefern als welche danach.

[Sebtis]

Aber was genau ist dieser Fehler denn dann, wenn er in meinem C++-Programm, meiner OpenOffice-Tabelle und meinem CASIO-Taschenrechner nicht kommt? Wäre das dann nicht ein generelles Problem, das bei jedem zu Grunde liegenden Code auftritt?

[Wolfgang Mix]

... und nebenbei:

Erstmal herzlich willkommen in der DP :dp:

[Luckie]

Es kommt natürlich noch auf die Genauigkeit der Datentypen an. Eventuell sind sie bei C++ und dem Casio Rechner höher.

[Amateurprofi]

Es liegt weniger am Startwert als am Multiplikator 1.55.
Dieser läßt sich als Binärzahl nicht exakt darstellen.
Im letzten Durchlauf wird 672920 mit 1.55 (bzw. einem Wert, der etwas geringer ist als 1.55)
multipliziert. Das Ergebnis ist ein Wert, der knapp unter 1043026 liegt, und Floor
macht daraus 1043025.
Schau dir das doch mal im Debugger an. Da kannst du dir die FPU-Register in ihrer
binären Darstellung ansehen, und dann wird deutlich woran's liegt.

[Sebtis]

@Wolfgang Mix:
Danke ^^

Ihr habt mir schon viele Male geholfen, auch wenn ich nicht angemeldet war *G*

@ Luckie:
An die Genauigkeit hab ich auch schon gedacht, aber:
1.
C++ long double 3,4E-4932 1,1E+4932
Delphi extended 3.6E-4951 1.1E+4932
und son CASIO-Rechner is doch nich genauer als das.

2.
reden wir hier von dem wert 1043025 bzw. 1043026, also knapp 1 million...

3.
würde das Genauigkeitsproblem ja wieder bedeuten, dass höhere werte noch eher betroffen sind...


@Amateurprofi:
Das klingt gut. Und was macht C++ da jetz anders? ^^