Wieso Endlosschleife?
-
Wegen der Ungenauigkeit von Fließkommazahlen. Die wurde in anderen Zusammenhängen schon in verschiedenen Threads hier im Forum diskutiert.
Nimm entweder Ganzzahlen, wie schon vorgeschlagen, oder ändere Deine Abbruchbedingung in:
for (f = 0.0; f < 1.0; f += 0.1)
-
also mal ehrlich, wofür braucht man in "realen anwendungen" die keine wissenschaftlichen berechnungen durchführen floats? grafiken werden dann immer wischiwaschi und langsamer sind sie auch
-
float == wischiwaschi schrieb:
also mal ehrlich, wofür braucht man in "realen anwendungen" die keine wissenschaftlichen berechnungen durchführen floats? grafiken werden dann immer wischiwaschi und langsamer sind sie auch
wischiwaschi xD
-
float == wischiwaschi schrieb:
also mal ehrlich, wofür braucht man in "realen anwendungen" die keine wissenschaftlichen berechnungen durchführen floats? grafiken werden dann immer wischiwaschi und langsamer sind sie auch
Sind floats auf "grossen" Systemen wirklich so viel langsamer? Ich hab das nie gemessen, und lese immer wieder widersprüchliches darüber. Z.B. das hier:
http://www.lua.org/pil/2.3.html schrieb:
Moreover, most modern CPUs do floating-point arithmetic as fast as (or even faster than) integer arithmetic.
or even faster?
-
mngbd schrieb:
Sind floats auf "grossen" Systemen wirklich so viel langsamer? Ich hab das nie gemessen, und lese immer wieder widersprüchliches darüber. Z.B. das hier:
http://www.lua.org/pil/2.3.html schrieb:
Moreover, most modern CPUs do floating-point arithmetic as fast as (or even faster than) integer arithmetic.
or even faster?
habs selbst noch nicht gemessen... aber evtl. sind das gute benchmarks (ich weiß die sind von 2006 und aus der computerwoche)?
http://www.computerwoche.de/bild-zoom/2016541/7/379870/d2e1467-media/
http://www.computerwoche.de/bild-zoom/2016541/8/379877/d2e1672-media/
-
Belli schrieb:
Wegen der Ungenauigkeit von Fließkommazahlen. Die wurde in anderen Zusammenhängen schon in verschiedenen Threads hier im Forum diskutiert.
Nimm entweder Ganzzahlen, wie schon vorgeschlagen, oder ändere Deine Abbruchbedingung in:
for (f = 0.0; f < 1.0; f += 0.1)Das tut es auch nicht sauber, läuft sicher nur bis 0.9, nicht wie gewünscht bis 1.0.
Also abändern in for(f=0.0;f<1.001;f+=0.1), dann läuft es.
-
mussten das in der UNI mal benchen:
Fazit: floats haben keinen signifikanten Geschwindigkeitsnachteil. die extra dafür vorgesehene FPU erfüllt ihren Job also wunderbar(waren <10% Unterschied)
-
orioon schrieb:
mussten das in der UNI mal benchen:
Fazit: floats haben keinen signifikanten Geschwindigkeitsnachteil. die extra dafür vorgesehene FPU erfüllt ihren Job also wunderbar(waren <10% Unterschied)
also wenn ich den benchmark richtig interpretiere fehlen mir 1 von 5 und damit ca. 20%
-
Noch mal btw, in C++ lässt sich der Unterschied per cout.precision leicht erkennen:
#include <iostream> int main() { std::cout.precision(20); for(int i = 0; i < 15; ++i) { static float f = 0.0; f += 0.1; std::cout << f << "\n"; } }
Nahezu erschreckend große Abweichungen, woher kommt das eigentlich mit der Ungenauigkeit?
-
WIR SIND HIER IM ANSI C SUBFORUM!!! und die frage warum beantwortest dir selbst wenn du dich mal mit fließkommazahlen beschäftigst.
-
__-- schrieb:
orioon schrieb:
mussten das in der UNI mal benchen:
Fazit: floats haben keinen signifikanten Geschwindigkeitsnachteil. die extra dafür vorgesehene FPU erfüllt ihren Job also wunderbar(waren <10% Unterschied)
also wenn ich den benchmark richtig interpretiere fehlen mir 1 von 5 und damit ca. 20%
stimmt, in deinen ist das etwas größer.
hab grad nochmal meine Ergebnisse angeschaut:
Fließkomma kostet viel Geschwindigkeit, wenn der Compiler nicht optimiert (>50% Zeitzuwachs). Je besser die Optimierungen, desto verschwindender wird es. (< 10% Unterschied auf einmal, natürlich wurden bei Integern auch -O2 genutzt)Weiß jetzt aber leider auch nicht, warum Optimierungen bei FPU Berechnungen so viel im Vergleich bringen...
Kann das jemand aufklären oder eine gute Vermutung anstellen?
-
orioon schrieb:
oder eine ~~gute/~~schlechte Vermutung anstellen?
evtl. rechnen sie so lang wie möglich mit int's
-
__-- schrieb:
orioon schrieb:
oder eine ~~gute/~~schlechte Vermutung anstellen?
evtl. rechnen sie so lang wie möglich mit int's
Nein, jede Arithmetik mit float erfolgt ohne int mit Mantisse und Exponent. Bei den ersten PCs wurde die Arithmetik softwaremässig langsam emuliert oder man musste für viel Geld einen CoProzessor kaufen. Soweit ich weiss arbeitet dieser hardwaremässig auf der Basis 2, also binär. Daraus ergibt sich die hohe Geschwindigkeit. Heute ist der CoProzessor eingebauter Standard.
edit: Und noch ein Wort zur (Un)Genauigkeit. Floats sind numerisch höchst genau innerhalb ihres darstellbaren Wertebereiches. Die vermeintlichen Ungenauigkeiten ergeben sich erst dann, wenn erfolgte Berechnungen dezimal betrachtet werden. Dann ist z.B. 1.0000000 0.9999999 und numerisch trotzdem exakt. Wer also Abfragen mit Floats machen will darf nicht auf einen festen Dezimalwert wie 1.00 abfragen, sondern muss einen Toleranzwert z.B eps = 0.0001 berücksichtigen. Macht man das nicht hat man wie hier eine Endlosschleife.
-
orioon schrieb:
mussten das in der UNI mal benchen:
Fazit: floats haben keinen signifikanten Geschwindigkeitsnachteil. die extra dafür vorgesehene FPU erfüllt ihren Job also wunderbar(waren <10% Unterschied)
Auf welcher Architektur und verglichen mit welcher int-Breite? Ein Mittel aus den normalen Zahlenoperationen, oder irgendwie gewichtet? (Ich dividiere weniger als ich multipliziere.)
Incocnito schrieb:
Noch mal btw, in C++ lässt sich der Unterschied per cout.precision leicht erkennen:
...Wir alle lieben Seiteneffekte. Die würzen das Leben.
-
mngbd schrieb:
Wir alle lieben Seiteneffekte. Die würzen das Leben.:)
Nach gut 50 Jahren Programmierung noch Seiteneffekte?
Was zum Teufel lernt ihr heute an einer Uni?Und überhaupt: dafür braucht man kein Studium, es ist einfaches Handwerkzeug!
-
berniebutt schrieb:
Nach gut 50 Jahren Programmierung noch Seiteneffekte?
Magst du die nicht?
-
Was erwartest Du denn, wenn jemand mit 50 Jahren "Programmiererfahrung" behauptet:
berniebutt schrieb:
Floats sind numerisch höchst genau innerhalb ihres darstellbaren Wertebereiches. Die vermeintlichen Ungenauigkeiten ergeben sich erst dann, wenn erfolgte Berechnungen dezimal betrachtet werden. Dann ist z.B. 1.0000000 0.9999999 und numerisch trotzdem exakt.
-
Belli will der lateinischen Bedeutung seines Benutzernamens offensichtlich gerecht werden.
daddeldu! :p