Wir haben folgende Aufgabe gestellt bekommen.
( a ) Was erwarten Sie (ungefähr) als Ausgabewert des Programms?
( b ) Was passiert tatsächlich? Warum? Tipp: Es kann helfen, die auskommentierten Codezeilen 10 . . . 12 wieder zu aktivieren.
( c ) Schreiben Sie das Programm so um, dass es den ursprünglich angedachten Zweck erfüllt.
Was ich mir dazu gedacht habe:
(a) Man erwartet als Ausgabewert halt eine Zahl in der Nähe von 1.0E8f.
(b) Was halt wirklich passiert ist eine Endlosschleife, da die Abbruchbedingung nie erfüllt wird.
(c) Jetzt wird es etwas kniffliger. Punkt bei dem ganzen ist die Addierung mit einer sehr sehr kleinen Zahl. Es kommt dadurch zu Rundungsproblemen., sodass halt das Limit dann nicht erreicht ist. aktiviert man die auskommentierten Zeilen sieht man das recht deutlich.
Mein Problem bei dem ganzen ist, dass ich mir nicht sicher bin wie man das Problem lösen kann. Wenn ich halt nicht n += 0.1 dort stehen habe, sondern n+=10 oder etwas ähnliches funktioniert das. Das wäre zwar Möglich, aber entspricht ja nicht der Aufgabe. Oder? Also wäre es wohl besser keine Gleitkommazahlen zu benutze, sondern einen feste Anzahl an durchläufen. Ich weiß nur nicht wie ich das ganze dann umschreiben soll.
Was passiert, wenn man anstatt sum einfach n mit limit vergleicht. Dann hätte man keinen Vergleich von Gleitkommazahlen mehr. Und es kommt auch ein recht sinnvolles ergebnis bei raus.
Java:
// Test floating point arithmetic...
public class aufg05_1 {
public static void main( String args[] ) {
// calculate the sum of 1E9 unprecise numbers
int n = 0;
float sum;
float limit = 1.0E8f;
for( sum = 0; sum < limit; sum += 0.1 ) {
n++;
// if ((n % 100000) == 0) {
// System.out.println("n="+ n + " sum="+ sum + " target="+ (n*0.1));
// }
}
System.out.println("sum is " + sum + " compared to " + (n*0.1));
}
}( a ) Was erwarten Sie (ungefähr) als Ausgabewert des Programms?
( b ) Was passiert tatsächlich? Warum? Tipp: Es kann helfen, die auskommentierten Codezeilen 10 . . . 12 wieder zu aktivieren.
( c ) Schreiben Sie das Programm so um, dass es den ursprünglich angedachten Zweck erfüllt.
Was ich mir dazu gedacht habe:
(a) Man erwartet als Ausgabewert halt eine Zahl in der Nähe von 1.0E8f.
(b) Was halt wirklich passiert ist eine Endlosschleife, da die Abbruchbedingung nie erfüllt wird.
(c) Jetzt wird es etwas kniffliger. Punkt bei dem ganzen ist die Addierung mit einer sehr sehr kleinen Zahl. Es kommt dadurch zu Rundungsproblemen., sodass halt das Limit dann nicht erreicht ist. aktiviert man die auskommentierten Zeilen sieht man das recht deutlich.
Mein Problem bei dem ganzen ist, dass ich mir nicht sicher bin wie man das Problem lösen kann. Wenn ich halt nicht n += 0.1 dort stehen habe, sondern n+=10 oder etwas ähnliches funktioniert das. Das wäre zwar Möglich, aber entspricht ja nicht der Aufgabe. Oder? Also wäre es wohl besser keine Gleitkommazahlen zu benutze, sondern einen feste Anzahl an durchläufen. Ich weiß nur nicht wie ich das ganze dann umschreiben soll.
Was passiert, wenn man anstatt sum einfach n mit limit vergleicht. Dann hätte man keinen Vergleich von Gleitkommazahlen mehr. Und es kommt auch ein recht sinnvolles ergebnis bei raus.
Zuletzt bearbeitet:
