Ich bin C++-Anfänger und nehme gerade das Buch "Der C++-Programmierer" durch. Ich bin grad bei der Darstellung reeller Zahlen. In einem Beispiel (das ich hier leicht abgeändert habe) soll aufgezeigt werden, dass C++ beim Rechnen mit reellen Zahlen in bestimmten Fällen ungenaue Ergebnisse liefert. Für mich sind die Ergebnisse aber nicht nur ungenau, sondern machen überhaupt keinen Sinn..

#include<iostream>
using namespace std;

int main() {

float a = 1.234567E-7;
float b = 1.000000;
float c = -b;
float s1 = a+b;
cout << s1 << endl;   // Konsolenausgabe: 1
s1 += c;
cout << s1 << endl;    // Konsolenausgabe: 1.19209e-07
cout << a+b+c << endl; // Konsolenausgabe: 1.23457e-07

return 0;
}

Im obigen Code, wird erst s1 = a+b ausgegeben. Der ausgegebene Wert ist 1, was ich soweit auch verstehe. a ist viel kleiner als b und wird deshalb bei der Addition ignoriert.
Im nächsten Schritt wird nun zu s1 der nächste Summand c = -b = -1 addiert. Was ich nun erwarten würde, ist dass die Summe s1 = 0 ist, da sie ja vorher 1 war und 1 + c ja 0 ergibt. Stattdessen wird aber der Wert 1.19209e-07 augegeben. Bahnhof ftw.
Im nächsten Schritt wird dann die Summe a+b+c in einem Rutsch berechnet und ausgegeben. Da dachte ich mir, C++ wäre wenigstens konsequent, und würde wieder
1.19209e-07 ausgeben. Aber nein, diesmal erscheint der Wert 1.23457e-07..

Kann mir jemand erklären, wie diese einzelnen Ergebnisse zustande kommen? Besonders die 1.19209e-07 kann ich überhaupt nicht nachvollziehen, mir fällt keine Rechnung ein, durch die man mit den gegebenen Werten a, b, und c auf diese Zahl kommt.

Danke schonmal im Voraus für Antworten.

Kann mir jemand erklären, wie diese einzelnen Ergebnisse zustande kommen? Besonders die 1.19209e-07 kann ich überhaupt nicht nachvollziehen, mir fällt keine Rechnung ein, durch die man mit den gegebenen Werten a, b, und c auf diese Zahl kommt.

Das ist genau das, was mit "ungenauen Ergebnissen" gemeint ist. Reelle Zahlen lassen sich binär nicht beliebig genau darstellen, weil du (annähernd) unendlich viele Nachkommastellen haben kannst (double d = 1.0 / 3.0).

Erstmal ganz dumm gefragt: Weißt du, was "1.19209e-07" bedeutet? Diesen Wert kannst du auch nur dann rechnerisch nachvollziehen, wenn du die exakte binäre Darstellung der beteiligten Werten kennst.

#include<iostream>
#include<iomanip>

int main() {

float a = 1.234567e-7; 
float b = 1.000000; 
float c = -b; 
float s1 = a+b; 
std::cout << std::fixed << std::setprecision(10) << s1 << std::endl;
s1 += c;
std::cout << s1 << std::endl;
std::cout << a+b+c << std::endl;

return 0;
}

Wenn du das meintest.
Die Rechnung ist doch eigentlich richtig?
Per Hand:
a = 1.234567e-7 = 0.0000001234567
b = 1
x = -1
s1 = 1.0000001234567
s1 += c; s1 = 0.0000001234567
a+b+c = 0.0000001234567

Es entstehen bloß bei den Rechnungen verschiedene ungenaue Lösungen

EDIT: Bin selber noch Anfänger, versuche nur zu helfen

@daddyfelix
Also 1.19209e-07 ist in der "recheninternen Repräsentation" einmal die Mantisse 1.19209 sowie der Exponent e-07, sowie die jeweiligen Vorzeichen bits der beiden.
für die binäre Darstellung aller Werte müsst ich mich erst mal ne Weile hinhocken.
Was ich aber so oder so nicht verstehe, ist dass wenn ich die Rechnung a+b+c in die zwei Rechnungen s1 = a+b und s1+=c splitte unterschiedliche Werte herauskommen.

@xStrykex
Stimmt, die 1.234567e-7 kann ich nachvollziehen. Aber wie kommt dann das Programm auf die 1.19209e-07?

Da das die beiden grundlegenden Fehler der Numerik sind (und auch die beiden ersten, die auf Wikipedia aufgelistet werden), gehe ich mal davon aus, dass dieser Rechenweg mit Absicht so gewählt worden ist, um als abschreckendes Beispiel zu dienen.

edit: Der Threadersteller hat noch etwas gefragt, während ich schrieb:

Stimmt, die 1.234567e-7 kann ich nachvollziehen. Aber wie kommt dann das Programm auf die 1.19209e-07?

Ist hoffentlich nun klar, siehe oben

Was ich aber so oder so nicht verstehe, ist dass wenn ich die Rechnung a+b+c in die zwei Rechnungen s1 = a+b und s1+=c splitte unterschiedliche Werte herauskommen.

Spekulation ohne jetzt genau darüber nachzudenken: Diese Rechnung darf komplett im Rechenwerk durchgeführt werden, ohne zwischendurch in eine Variable begrenzter Genauigkeit zurück geschrieben zu werden. Das Rechenwerk ist wesentlich genauer (in der Regel 80 Bit), da reicht die hier nötige Genauigkeit für die Zwischenschritte locker aus. Wie genau Rechnungen mit Fließkommazahlen durchgeführt werden ist im C++-Standard (bewusst) nur sehr vage beschrieben. Auf den allermeisten Systemen wird jedoch nach IEEE 754 gerechnet, außerdem kannst du auf einem x86(-64) davon ausgehen, dass entweder der x87-Coprozessor oder die SSE-Einheit zum Rechnen benutzt wird (je nach Optimierungseinstellungen).

http://www.tutorials.de/c-c/381980-problem-gleitkommatypen-assoziativgesetz.html#post1975101

std::cout << a << std::endl;

stehen.

Im vorherigen Fall müssen die Additionen aber tatsächlich durchgeführt werden, weil du ein Zwischenergebnis ausgibst, da kann nicht optimiert werden.

Ist nur eine Vermutung, klingt für mich aber plausibel.

Ist jetzt nur eine Vermutung, aber evtl. wird die Addition im letzten Fall einfach wegoptimiert, da sinnlos.

Nein, Fließkommaoperationen können in der Regel nicht wegoptimiert werden, da die Regeln sehr kompliziert sind. Siehe eben dieses Beispiel, wieso das nicht einfach alles weggekürzt werden kann. Es ist schon immer wieder für eine Überraschung gut, wenn gewisse Operationen zur Compilezeit durchgeführt werden (das könnte hier übrigens tatsächlich passieren, wenn man die Optimierungen anschaltet), weil die dann auch gerne mal mit anderer Präzision durchgeführt werden als man das erwarten würde (z.B. mit 64-Bit-Genauigkeit, anstatt mit 80-Bit). Ich habe oben schon genau erklärt, was vermutlich passiert.

Also 1.19209e-07 ist in der "recheninternen Repräsentation" einmal die Mantisse 1.19209 sowie der Exponent e-07, sowie die jeweiligen Vorzeichen bits der beiden.

Nö - Dein PC denkt binär, nicht dezimal

climits schrieb:

für die binäre Darstellung aller Werte müsst ich mich erst mal ne Weile hinhocken.

rechne mal 2^-23 aus

Edit
@ Walter
Oh eh, verblüffend

http://www.tutorials.de/c-c/381980-problem-gleitkommatypen-assoziativgesetz.html#post1975101

wenn du die nicht geltende assoziativität meinst ist das nichts neues. dass es ungeneuigkeiten gibt beim rechnen mit gleitkomma zahlen lernt men sehr schnell. dass man diesem "phänomen" einen name gibt bzw. es mit fehlender assoziativiät ausdrückt kam bei uns dann im ersten semester in der programmier vorlesung

kleines beispiel:

float x = 2304.0f;
float y = -4096.0f;
float z = 4096.001953125f;

float e1 = x*(y+z);
float e2 = x*y + x*z;

cout << e1 << " == " << e2 << " (laut der Mathematik!)" << endl;

die 1.234567e-7 kann ich nachvollziehen.

.. glaub' ich nicht. Ersetze mal Zeile 13 durch

std::cout << b+c+a << std::endl;

versuch einfach mal die 3.75 binär darzustellen (da reichen 8bit locker aus)
und danach fängst du mal die 3.6 an...

mantiz schrieb:

Ist jetzt nur eine Vermutung, aber evtl. wird die Addition im letzten Fall einfach wegoptimiert, da sinnlos.

Nein, Fließkommaoperationen können in der Regel nicht wegoptimiert werden, da die Regeln sehr kompliziert sind. Siehe eben dieses Beispiel, wieso das nicht einfach alles weggekürzt werden kann. Es ist schon immer wieder für eine Überraschung gut, wenn gewisse Operationen zur Compilezeit durchgeführt werden (das könnte hier übrigens tatsächlich passieren, wenn man die Optimierungen anschaltet), weil die dann auch gerne mal mit anderer Präzision durchgeführt werden als man das erwarten würde (z.B. mit 64-Bit-Genauigkeit, anstatt mit 80-Bit). Ich habe oben schon genau erklärt, was vermutlich passiert.

Ok, auch wenn es nicht wegoptimiert wird, so ergibt sich durch die rechts-assioziativität von "+", dass erst "b+c" gerechnet wird, was "0" ergibt, also bleibt nur "a" übrig, was von den Auswirkungen her das gleiche ist.

Hab's jetzt nur mal schnell im Taschenrechner nachvollzogen, wenn ich "a+b" auf 8 Nachkommastellen abschneide und anschließend "+c", also "-1" rechne, dann lande ich bei "1,19...e-7". Die Nachkommastellen unterscheiden sich zwar noch, aber mir ist das Ergebnis nah genug dran. Dann würde ich das also auf die rechts-assioziativität schieben.

Hab's jetzt nur mal schnell im Taschenrechner nachvollzogen, wenn ich "a+b" auf 8 Nachkommastellen abschneide und anschließend "+c", also "-1" rechne, dann lande ich bei "1,19...e-7". Die Nachkommastellen unterscheiden sich zwar noch, aber mir ist das Ergebnis nah genug dran. Dann würde ich das also auf die rechts-assioziativität schieben.

Tja, nur leider kommt bei c + b + a auch 1.23457e-07 heraus:
http://ideone.com/RAuLpg

Bei "c + a + b" tritt der "Fehler" übrigens auf: http://ideone.com/OOQr41

Ok, ich gebe auf.

Bei "c + a + b" tritt der "Fehler" übrigens auf: http://ideone.com/OOQr41

Und deswegen muss man immer genau aufpassen, welche Größenordnungen bei Zahlen zu erwarten sind und wie man daher seine Ausdrücke genau aufschreibt. Numerik ist nicht einfach.

Werner_logoff schrieb:

climits schrieb:

die 1.234567e-7 kann ich nachvollziehen.

.. glaub' ich nicht. Ersetze mal Zeile 13 durch

std::cout << b+c+a << std::endl;

Kommt bei mir wieder das selbe, also 1.234567e-7 raus, was aber auch nicht verwunderlich ist denn auch hier..

mantiz schrieb:

Bei "c + a + b" tritt der "Fehler" übrigens auf: http://ideone.com/OOQr41

Tritt der Fehler bei mir nicht auf, bzw. ich kriege wieder 1.234567e-7 statt 1.19209e-07 ausgegeben. Keine Ahnung woran das liegt. Vielleicht weil ich einen AMD nutze? Mit Rechenarchitektur kenn ich mich nun überhaupt nicht aus.
Wundern tut es mich aber dass es zumindest bei mantiz und auf der Internetseite tatsächlich einen Unterschied macht, ob man nun a+b+c oder c+a+b rechnet. Da wird in einem Fall dann wie SeppJ meinte, wohl das "Rechenwerk" mit 80 bit genutzt (oder SSE, x87...) und im anderem Fall aus irgendwelchen Gründen nicht.