Real, Single, Double = ungenau!?

[Patrick]

Hallo,

So was komisches ist mir noch nicht untergekommen.
Führt man den folgenden Quellcode mit i = Real, Single oder Double aus rechnet er schlicht und einfach falsch.

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var i : single;
begin
i:=0;
repeat
  i:=i+0.1;
  ListBox1.Items.Add(FloattoStr(i));
until i>100;
end;

Mit Extendend hingegen funktioniert es. Wahrscheinlich "noch", wenn ich weiter rechnen würde, habe ich bestimmt den gleichen fehler.

Also was ist das, kann ich diesen Fehler irgendwie verhindern?

[PRehders]

Hallo,
den Fehler kannst du letztendlich nicht verhindern; 0.1 sieht für uns (Dezimalrechner) zwar recht hübsch simpel aus, ist aber für einen (normalen) Computer (binär) eine kleine Katastrophe und lässt sich nur näherungsweise darstellen. Daher addierst du in der Schleife die Ungenauigkeit in der Darstellung immer weiter auf, bis es dann richtig sichtbar wird.
Auch die Verwendung von Extended bringt dir nur zeitweise Erleichterung.
Das ist auch der Grund für die Regel, niemals(!) solche Werte auf Gleichheit abzufragen, sondern immer mit Schranken zu arbeiten, also z.B.

Delphi-Quellcode:

if RealWert >= -0.1 AND RealWert <= +0.1 ...

statt

Delphi-Quellcode:

if RealWert = 0.0 ...

Bis dann

Peter

[Robert Marquardt]

Man bedenke das die reellen Zahlen ueberabzaehlbar unendlich sind. Alle Datentypen koennen aber nur einen endlichen Ausschnitt davon abbilden. Es gibt also immense Verluste bei der Erfassung aller Zahlen.

[yankee]

ich dachte immer, real, double, usw. sind imprinzipo nichts anderes als int-werte, nur dass die kommastelkle gespeichert ist (bei Fließkommavariablen) oder das komma an einer festen stelle ist (bei festkommavariablen).
Wenn dies so wäre, würde der Test aber funzen. Kann mir jemand erklären, wie das läuft?

[PRehders]

Hallo,

solche Zahlen haben nichts mit Integern zu tun, die interne Darstellung ist vollkommen anders. Aber du kannst es dir (sehr simpel) so vorstellen:
Im Dezimalsystem steht direkt hinter dem Komma die Zehntelstelle, danach kommt die Hundertstel usw. also 10 hoch -1, 10 hoch -2 ...
Im Binärsystem ist es eigentlich genauso: Hinter dem Komma (wo immer das auch steht bzw. sich gedacht wird) steht die Halbstelle (2 hoch -1), danach folgt die Vietelstelle (2 hoch -2) usw.
Jetzt kannst du auch schon sehen, warum ein Computer solche Probleme mit 0.1 (dezimal!) hat: Versuche mal, diesen Wert durch die Summe binärer Bruchzahlen darzustellen. Das artet aus! Und es gelingt dir nie! Du kannst dich nur dem Wert nähern. Und das ist die Ursache für das Problem hier.
Wenn man einen Datentyp mit sehr vielen Binärstellen nimmt, kann man noch einigermaßen annähern, aber irgendwann kommt der Darstellungsfehler durch.
Auf Computern werden solche Bruchzahlen so dargestellt, dass man einige Bits für die Dimension benutzt (also 2 hoch x) und den Rest für die eigentliche Zahl, wobei man definiert, dass diese immer als 0.yyyyy dargestellt wird. Das "0." kann man dann also weglassen.
Einige Bits werden auch benutzt, um besondere Zahlen zu kennzeichnen, wie "Unendlich" oder "NotANumber" (heisst wirklich so!), oder Sonderbedingungen in der dargestellten Zahl.

Bis dann

Peter

[Sanchez]

@yankee
Schau dir mal diesen Thread an -> http://www.delphipraxis.net/internal...light=mantisse

Da siehst du, wie Gleitkommazahlen gespeichert werden.

grüße, daniel

[schöni]

Hallo!

Ich lese grad den Thread hier. Und da entsteht bei mir die Frage, mit welchen Verfahren in der Wissenschaft solche Fehler eliminiert werden. Wie hoch ist die maximal erreichbare Rechengenauigkeit? Aus der Elektronik weiß ich, das es Verfahren der Fehlerrechnung gibt. Zum Beispiel ist der Meßfehler eines A/D Wandlers bekannt und wird in einer Korrekturrechnung eliminiert. Auf den PC übertragen hiße das ja, das generell überall mit Extended gerechnet wird, oder mit Double...., Wichtig ist, das der Fehler immer gleich groß ist, damit er rausgerechnet werden kann.

es grüßt schöni

[Robert Marquardt]

Fehlerrechnung ist eine Wissenschaft fuer sich.
Die gaengigste Berechnung ist Fast Fourier Transformation.
Das ist eine Matrixbrerechnung und es gibt nicht allzuviele Spezialisten
(und ich bin definitiv keiner) die wissen wie man genaue Ergebnisse bekommt.

[dizzy]

Zitat:

Zitat von Sanchez

@yankee
Schau dir mal diesen Thread an -> http://www.delphipraxis.net/internal...light=mantisse

Da siehst du, wie Gleitkommazahlen gespeichert werden.

Und hier in ganz ausführlich ;)

[PRehders]

Zitat:

Zitat von schöni

Hallo!

Aus der Elektronik weiß ich, das es Verfahren der Fehlerrechnung gibt. Zum Beispiel ist der Meßfehler eines A/D Wandlers bekannt und wird in einer Korrekturrechnung eliminiert. Auf den PC übertragen hiße das ja, das generell überall mit Extended gerechnet wird, oder mit Double...., Wichtig ist, das der Fehler immer gleich groß ist, damit er rausgerechnet werden kann.

Hallo,

das hat leider mit der Darstellungsgenauigkeit nicht unbedingt etwas zu tun. Das Thema ist hier, dass bestimmte Dezimalzahlen nicht binär dargestellt werden können. Es tritt ein Darstellungsfehler auf, der sich auch nicht eliminieren lässt, da er nicht bekannt ist. In der Messtechnik geht man in einigen Bereichen davon aus, dass sich ein immer gleich gearteter Messfehler ergibt, der dan durch Differenzbildung verschwindet; das ist hier aber nicht der Fall. Manche Zahlen lassen sich exakt darstellen, manche nicht. Der tatsächliche Inhalt einer Real-Variable, egal welche Grösse (= Genauigkeit) sagt ja nichts darüber aus, welcher Wert "eigentlich gemeint" war.
Die Ungenauigkeit ist vorhanden, sie geht auch nicht weg, wenn man es aber weiss, kann man damit umgehen.

Bis dann

Peter