Nutzen von Fließkommazahlen
-
Dravere schrieb:
Ich habe dies nicht für technischwissenschaftliche Rechnungen vorgeschlagen, sondern für Währungsrechnungen, also für die Verwendung in der Finanzwirtschaft und genau dafür wurden diese zusätzlichen Gleitkommazahlen geschaffen.
Wie schön, daß Du nicht einmal merkst, daß exakt in dem von Dir geschlagenem Anwendungsfeld es trotzdem die schon erwähnten Probleme gibt!
-
seldon schrieb:
Und da sind 15 Stellen Genauigkeit mehr als ausreichend, zumal vieles eh Ansichts- oder Konventionssache ist.
Fehlerfortpflanzung ist wohl für viele ein Fremdwort. 15 Stellen Genauigkeit wären wundervoll, wenn ein jedes Ergebnis damit ausgegeben würde. Allerdings ist die effektive Genauigkeit bei einer Berechnung oftmals sehr viel geringer, und der Rest der Stellen im Grunde nur Rauschen des Algorithmus. Das wird leider viel zu oft vergessen.
-
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?
-
~john schrieb:
Dravere schrieb:
Ich habe dies nicht für technischwissenschaftliche Rechnungen vorgeschlagen, sondern für Währungsrechnungen, also für die Verwendung in der Finanzwirtschaft und genau dafür wurden diese zusätzlichen Gleitkommazahlen geschaffen.
Wie schön, daß Du nicht einmal merkst, daß exakt in dem von Dir geschlagenem Anwendungsfeld es trotzdem die schon erwähnten Probleme gibt!
Willst du eigentlich alles bewusst falsch verstehen? Lies bitte nochmals, was ich wie geschrieben habe.
Neue Gleitkommazahlen des neuen Standards mit höherer Genauigkeit und neuer Rechnungskonvention für die Finanzwirtschaft. So schwer zu verstehen? Ich sage nicht, dass dadurch alle Probleme eliminiert werden! Aber sie werden deutlich reduziert und reichen meistens für die Finanzen.@SeppJ,
Ich kann deine Fragen schlecht beantworten. Das einzige, was ich dazu sagen kann, ist, dass Motoren simuliert wurden. In kleinen Intervallen (ca. 1 - 2 Millisekunden) wurde die Position der Motoren aktualisiert und danach über Odometrie die aktuelle Position des Vehikels berechnet. Die Motoren hatten eine sehr geringe Geschwindigkeit (0,1 - 0,4 m/s). Auch ging es grundsätzlich immer um den Nullpunkt im 2D Raum, wodurch nie wirklich grosse Zahlen entstanden. Auch der Winkel wurde immer wieder nach einer 360° Umdrehung zurückgesetzt.Wir haben dann zum Teil mitgerechnet und festgestellt, dass nach jeder Rechnung ein kleiner Fehler entstand. Dieser Fehler wurde abgespeichert als Position und mit dieser Position dann die nächste berechnet, Odometrie eben
Dadurch hat sich dieser Fehler immer fortgepflanzt und es kam zu der erwähnten Abweichung. Wir konnten den Fehler auf nichts anderes zurückführen.Am Projekt hat es nicht wirklich geschadet, da in der Realität die Motoren sowieso nicht durch einen einzigen Befehl gleichzeitig die Geschwindigkeit ändern konnten, sondern nur sequentiell von einer höheren Abstraktionsebene aus. Zudem liefen sie nicht genau gleich schnell. Daher haben wir in der Simulation gleich noch den Positionskorrektur-Code dazugeschaltet, welche wir aber eigentlich bei der Simulation nicht dabei haben wollten. Das war aber nur ein kleines Projekt, vielleicht haben wir wirklich was falsch gemacht.
Aber wie ich weiter vorne gesagt habe, hatte ich mal
doublefür Währungen eingesetzt. Ist allerdings schon länger her. Da gab es bereits bei Beträgen von mehreren Hunderttausend Abweichungen von 2 - 3 Cent. Spielte dort zwar keine Rolle, da der Betrag am Ende sowieso abgerundet wurde, da man keine xxxx.99 Rechnungen haben wollte. Die Kunden wurden somit nie irgendwie betrogen, die Firma hat aber über das Jahr ein paar Euro verloren
Wenn man die Beträge aber wirklich genau hätte haben wollen, so wäredoubledefinitiv der falsche Typ gewesen, weil er einfach zu ungenau ist.Mir ist es ehrlich gesagt ein Rätsel, wie du bisher noch nie Probleme mit
doublehaben konntest.Grüssli
-
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
-
