Nutzen von Fließkommazahlen
-
hibbes schrieb:
Kann man denn nicht irgendwie festmachen für was man Gleitkommazahlen ohne Einschränkung und besonderer Behandlung nutzen kann und wo man sehr genau aufpassen sollte?
Grob gesagt:
- Rechnungen mit reellen (nicht nur rationalen!) Zahlen (oder allgemein kontinuierlichen Mengen)
Fließkommatypen und aufpassen!- Rechnungen mit ganzen oder rationalen Zahlen (oder allgemein mit abzählbaren Mengen)
Ganzzahltypen oder spezialisierte Klassen die auf Ganzzahltypen basieren. Es ist nicht soooo wichtig auszupassen wie bei Fließkommazahlen.Worauf man aufpassen muss:
- Keine Vergleiche auf absolute Gleichheit
- Fehlerfortpfanzung bei Rechnungen beachten, besonders wenn in Algorithmen bestimmte Rechenschritte sehr oft wiederholt werden. Eigentlich sollte jeder der mit Fließkommazahlen arbeitet mal eine Numerikvorlesung gehört oder dieses Dokument gelesen haben.
- Eine große Sünde ist zum Beispiel das Subtrahieren von fast gleichen Zahlen. Bei einer Subtraktion summieren sich nämlich die absoluten Fehler. Wenn dann zusätzlich das Ergebnis klein ist, bekommt man einen riesigen relativen Fehler. Also die Rechnungen umstellen, dass so etwas nicht passiert. Wikipedia hat da ein schönes Beispiel@Dravere: Wie schon gesagt, ist Fließkomma eher der falsche Typ für Währungsrechnungen, weil Geldbeträge immer nur eine feste Anzahl Nachkommastellen haben. Und Sachen wie Zinsen sind normalerweise auch immer runde Dezimalbrüche.
Warum ich nie Probleme hatte? Nun, ich habe bisher hauptsächlich Simulationen mit einem Wärmebad gemacht oder Monte Carlo Methoden benutzt. Beides ist robust gegen kleine Fehler, falls man Probleme bekommt sollte man den Zeitschritt verkleinern. Ansonsten auch immer darauf, ein gutes Verfahren zu benutzen. Integration nach Euler ist zum Beispiel denkbar schlecht für Dynamiksimulationen. Und auch bei anderen Verfahren muss man halt wissen, wann man besser aufhören sollte (ein Blick auf die Gesamtenergie hilft als Hinweis).
-
-
wxSkip schrieb:
Ist es nicht so, dass bei long double nur der Exponent größer wird, die Mantisse aber immer noch 4 Byte lang ist?
Es ist von der jeweiligen Plattform abhängig was für ein Format mit long double verwendet wird. Zum Teil ist das das Intel 80Bit Format zuweilen auch 128Bit IEEE Quad.
-
Ich verstehe diese Diskussion um Gleitkommazahlen nun überhaupt nicht mehr. Dieser Datentyp bildet doch reelle Zahlen mit Mantisse und Exponent sehr genau ab und dafür gibt es ihn seitdem programmiert wird. Eine Abfrage auf Gleichheit erfolgt natürlich mit dem Absolutwert auf einen als hinreichend genau betrachteten Wert Epsilon. In der Finanzmathematik gibt es zwangsläufig Probleme, wenn die Saldi in Cent sein sollen und die dazwischen mit Gleitkomma erfolgten Berechnungen genauer sind.
Da soll schon mal jemand mit Zinsberechnungen und unauffälligen Rundungen sich selbst bereichert haben. Es ging, flog aber dennoch auf!
-
Dravere schrieb:
Willst du eigentlich alles bewusst falsch verstehen?
Du schreibst auch weiterhin Falsches, da gibt es nichts "absichtlich" falsch zu verstehen. Bei Verwendung von Dezimalarithmetik wird lediglich das Problem der Konvertierung vermieden. Alle anderen Probleme des Rechnens mit Gleitkommaarithmetik existieren weiterhin!
Dravere schrieb:
Ich sage nicht, dass dadurch alle Probleme eliminiert werden! Aber sie werden deutlich reduziert und reichen meistens für die Finanzen.
Und genau hier liegt das fundamentale Problem, Du siehst die Probleme mit Gleitkommaarithmetik nicht.
-
berniebutt schrieb:
Ich verstehe diese Diskussion um Gleitkommazahlen nun überhaupt nicht mehr. Dieser Datentyp bildet doch reelle Zahlen mit Mantisse und Exponent sehr genau ab
"Genau" ist im Zusammenhang mit Gleitkommaarithmetik ein relativer Begriff. Wenn man nichtlineare dynamische Systeme hat, dann ist recht schnell die Grenze der diversen Gleitkommatypen erreicht, und die Simulation liefert nur noch bedeutungslosen Schrott als Zahlenwerte. Irrationale Zahlen kann man mit einem Computer gar nicht darstellen, und für die rationalen Zahlen ist nur eine Teilmenge darstellbar.
-
~john schrieb:
... Und genau hier liegt das fundamentale Problem, Du siehst die Probleme mit Gleitkommaarithmetik nicht.
Ich vermag das fundamentale Problem der Gleitkommaarithmetik auch nicht zu sehen. Beim Bäcker kann man nur ganze Brötchen kaufen. Beim Metzger wird dagegen abgewogen. Hier reicht die Genauigkeit auf ein Gramm, woanders nicht.
-
~john schrieb:
"Genau" ist im Zusammenhang mit Gleitkommaarithmetik ein relativer Begriff.
Diese Einschränkung von 'genau' habe ich als Ingenieur noch nicht gewusst. Danke, wir sind hier aus unterschiedlicher fachlicher Herkunft - und das macht das Salz an der Suppe in diesem Forum. :p
-
berniebutt schrieb:
~john schrieb:
... Und genau hier liegt das fundamentale Problem, Du siehst die Probleme mit Gleitkommaarithmetik nicht.
Ich vermag das fundamentale Problem der Gleitkommaarithmetik auch nicht zu sehen. Beim Bäcker kann man nur ganze Brötchen kaufen. Beim Metzger wird dagegen abgewogen. Hier reicht die Genauigkeit auf ein Gramm, woanders nicht.
Ein Problem ist dass zum Beispiel zehn mal 10 cent nicht bei jeder Implementierung 1 Euro ist um nur mal eines der vielen fundamentalen Probleme raus zu picken. Man kann sich also nicht darauf verlassen das die Ergebnisse 100% korrekt sind. Da brauch man garkeine großen Anwendungen sich für ausdenken, schon wenn Heinz Otto die ersten Tage programmiert und sich ein kleines Haushaltsbuch programmiert kann er mit Gleitkommazahlen schon auf die Nase fallen.
Sie sind einfach nur dort einzusetzen wo solche Fehler toleriert werden.
-
Kann man das irgendwie machen, dass bei einem Thread am Ende wieder die Beiträge vom Anfang angezeigt werden? Dann könnte man diese Kreisdiskussion nämlich wunderbar abschließen
.
-
Aber bitte den Kreis nicht mit Gleitkommazahlen berechnen
-
