hi!
kann mir jemand erklären warum sich sqrt(2) in gleitkommaarithmetik nicht exakt berechnen lässt?
Ist das aufgrund des Rundungsfehlers oder gibt es andere Gründe auch noch dafür??
mfG
Gregor
Hallo.
kann mir jemand erklären warum sich sqrt(2) in
gleitkommaarithmetik nicht exakt berechnen lässt?
SQRT(2) ist eine irrationale Zahl. Das ist vereinfacht gesagt ein Dezimalbruch mit unendlicher Periodenlänge. Um exakt zu sein, müsstest Du ein Feld von unendlicher Länge haben - mithin unendlich viel Speicher. Dieser Rechner existiert noch nicht.
Gruß Eillicht zu Vensre
hi Gregor
eine korrekte antwort hast du ja schon bekommen. zusätzlich gibt es ein problem mit der implementierung von gleitkommazahlen, die in praktisch allen programmiersprachen angewendet wird. diese hat ein prinzipielles problem beim darstellen bestimmter zahlen (z.b. kann 0.1 nicht wirklich richtig dargestellt werden). dadurch gibt es recht nette effekte - bsp:
double a;
double b;
a = 8.0 / 10 ;
b = 7.0 / 10 + 0.1 ;
auf fast allen systemen ist nun a != b
(also a = 0.8 während b = 0.799999999999)
habs mit java nachgeprüft. meines wissens selbes problem in C und auf jeden fall in PHP. andere sprachen habe ich nicht kontrolliert.
lg
erwin
Hiho
eine korrekte antwort hast du ja schon bekommen. zusätzlich
gibt es ein problem mit der implementierung von
gleitkommazahlen, die in praktisch allen programmiersprachen
angewendet wird. diese hat ein prinzipielles problem beim
darstellen bestimmter zahlen (z.b. kann 0.1 nicht wirklich
richtig dargestellt werden).
Nur mal so: gibt es eine Implementierung (weil die Sachen ja meistens über den Prozessor laufen) die diese Probleme nicht hat? (abgesehen von, was weiß ich wie es richtig heißt: z.B. die Sachen die Yacas (und wahrscheinlich Mat…) dafür verwenden, also mit Darstellung als Zeichenkette (oder so?)))
mfg TLF
Hallo!
habs mit java nachgeprüft. meines wissens selbes problem in C
und auf jeden fall in PHP. andere sprachen habe ich nicht
kontrolliert.
Ich habe das gerade im .Net-Framework 2.0 ausprobiert, da kam sowohl beim Datentyp Single als auch bei Double immer 0.8 heraus. Das einzige was ich nicht geschaut habe, ob die Ausgabe in die Konsole eventuell etwas gerundet hat.
mfg
chris
Hallo TLF,
Nur mal so: gibt es eine Implementierung (weil die Sachen ja
meistens über den Prozessor laufen) die diese Probleme nicht
hat?
Ja, als BCD.
Da rechnet der Computer dann wie du und ich es mit Bleistift und Papier tun.
Allerdings willst du ja auch irgendwann ein Resultat erhalten, also muss die Anzahl zu berechnender Stellen bergrenzt werden, damit sich die CPU nicht zu Tode rechnet, wenn das Resultat unendlich viele stellen hat.
Somit gibt es auch hier Rundungsfehler.
Allerdings entfallen die Quantisierungsfehler, beim umrechnen von dezimaler in binäre Darstellung.
BCD wird meist von der FPU unterstützt (es gibt auch noch andere CPUs als den Pentium von Intel), ist aber langsamer als binär.
MfG Peter(TOO)
1 Like
Moien
zusätzlich
gibt es ein problem mit der implementierung von
gleitkommazahlen, die in praktisch allen programmiersprachen
angewendet wird.
Es gibt schon länger Implementierungen die das Problem nicht haben: Haskell kann z.B. mit Brüchen (Ratio ?) rechnen.
auf fast allen systemen ist nun a != b
(also a = 0.8 während b = 0.799999999999)
Wer Gleitkommanzahlen auf exakte Gleichheit vergleicht sollte nochmal ein paar Bücher zum Thema richtiges Programmieren lesen.
cu
hi
ich sehe schon - man soll nicht verallgemeinern. es gibt einen standard der ieee zum thema gleitkommadarstellung, und genau der hat diesen fehler. meines wissens nach hat auch der normale gleitkommateil der fpu dieses problem. dieses wird bewusst in kauf genommen, damit die berechnungen schön flott laufen.
c und c++ arbeiten standardmässig nach dem selben standard, einige andere sprachen (wie java) aus kompatibilitätsgründen auch.
offenbar verlassen sich alle darauf, dass die programmierer den standard gelesen haben und wissen, und dass man in bestimmten fällen runden muss.
es gib aber genug sprachen, die eher auf genauigkeit als auf performance achten und andere mittel der gleitkommadarstellung nutzen.
lg
erwin
Hallo TLF,
Nur mal so: gibt es eine Implementierung (weil die Sachen ja
meistens über den Prozessor laufen) die diese Probleme nicht
hat?Ja, als BCD.
Wieder was gelernt 
, thx.
Da rechnet der Computer dann wie du und ich es mit Bleistift
und Papier tun.
Allerdings willst du ja auch irgendwann ein Resultat erhalten,
also muss die Anzahl zu berechnender Stellen bergrenzt werden,
damit sich die CPU nicht zu Tode rechnet, wenn das Resultat
unendlich viele stellen hat.
Somit gibt es auch hier Rundungsfehler.
Allerdings entfallen die Quantisierungsfehler, beim umrechnen
von dezimaler in binäre Darstellung.BCD wird meist von der FPU unterstützt (es gibt auch noch
andere CPUs als den Pentium von Intel), ist aber langsamer als
binär.
Ja, hab ja auch AMD (ok, das zählt nicht … egal)
Da wir gerade dabei sind: kennt jemand eine kurze Beschreibung zu Gleitkommarechnung mit AMD64-Prozessoren (Assembler)?
Ich schaue mir gerade den Code, der von gcc generiert wird, an und bin etwas überrascht nur sse (oder so, „movss/mulss/cvtss2sd“) -Befehle zu sehen; ist das jetzt der Weg, den der Compiler nimmt, oder sind die normalen f…-Befehle für den x87 nicht mehr zeitgemäß?!
mfg TLF
Hallo Gregor,
kann mir jemand erklären warum sich sqrt(2) in
gleitkommaarithmetik nicht exakt berechnen lässt?
Ja.
Ist das aufgrund des Rundungsfehlers oder gibt es andere
Gründe auch noch dafür??
Ja. Und zwar unter anderem, weil Wurzel aus zwei eine irrationale Zahl ist, die du nicht nur auf einem Computer nicht „exakt“ darstellen kannst. Gehst du mal auf Wikipedia und guckst unter dem Stichwort „Euklid“ nach.
Grüsse,
Tim