Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Mir ist das Problem mit der Genauigkeit von Floatingpointzahlen per Zufall in einem Programm aufgefallen, da ich etwas mit einer Floatingpointzahl berechne und dann eine sehr kleine Zahl dazu addiere.
Das Bild beschreibt das Problem sehr anschaulich. Ich addiere einfach nur 0,1 und 0,2, aber das Ergebnis ist nicht 0,3 sondern 0,300000000000000044.
Die letzten beiden Stellen fallen den meisten wahrscheinlich gar nicht auf, aber ich brauche das exakte Ergebnis (0,3).
Ich habe keinen dieser Datentypen in Labview finden können aber ich kann mir nicht vorstellen, dass ich der einzige mit diesem Problem bin. Mit der Suche habe ich nichts zu dem Thema gefunden, aber vielleicht hat sich ja schon einmal jemand damit beschäftigt und weiß eine Lösung.
Einer der Grundsätze in allen Programmiersprache ist:
Vergleiche NIEMALS eine Floatingpointzahl auf Gleichheit sondern immer auf grösser oder kleiner, aus eben erwähnter Problematik.
Eine Möglichkeit wäre den Wert mal 10^x (x=Stelle der benötigten Zahl) zu rechnen und einen Integer zu verwenden, da das Problem nur bei Kommazahlen besteht
Dieser Beitrag soll weder nützlich, informativ noch lesbar sein.
Er erhebt lediglich den Anspruch dort wo er ungenau ist, wenigstens eindeutig ungenau zu sein.
In Fällen größerer Abweichungen ist es immer der Leser, der sich geirrt hat.
Rette einen Baum!
Diesen Beitrag nur ausdrucken, wenn unbedingt nötig!
23.07.2010, 10:59 (Dieser Beitrag wurde zuletzt bearbeitet: 23.07.2010 11:02 von jg.)
Numerische Operationen für Gleitkommazahlen sind in einem Computer NIE genau! Es wird immer einen Fehler geben.
Ein grundsätzliches Problem ist z.B. das Addieren von einer "sehr großen" und einer "sehr kleinen" Zahl.
Oder vielfaches Addieren ein- und derselben Zahlen, da sich dort die Rundungsfehler addieren.
Ist so, war schon immer so, wird wahrscheinlich auch noch länger so bleiben.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Es gibt ja auch das neue Format "Festkomma" (FXP). Wer also seine Milliarden-Transaktionen auf dem Finanzmarkt immer auf den letzten Pfennig genau berechnen will und dazu Labview verwendet - mit diesem Formt liegt er richtig.
Bei Gleitkommazahlen muß die Frage, ob 0.1 + 0.2 = 0.3 ist, unter Berücksichtigung der Maschinentoleranz gestellt werden. Dann kommt duchaus ein "Ja" heraus - es ist aber umständlich immer so zu fragen:
' schrieb:Einer der Grundsätze in allen Programmiersprache ist:
Vergleiche NIEMALS eine Floatingpointzahl auf Gleichheit sondern immer auf grösser oder kleiner, aus eben erwähnter Problematik.
Eine Möglichkeit wäre den Wert mal 10^x (x=Stelle der benötigten Zahl) zu rechnen und einen Integer zu verwenden, da das Problem nur bei Kommazahlen besteht
Gruss MNussbaumer
Ich vergleiche die Zahlen nicht, aber ich muss eine sehr kleine Kommazahl und eine kleine Kommazahl addieren.
Die Werte brauche ich später auch wieder für weitere Berechnungen.
Wenn ich das alles mal 10^x nehme habe ich ja immernoch das Problem, dass ich es nachher wieder in eine Kommazahl zurück wandeln muss und dann stehe ich doch wieder vor dem selben Problem.
' schrieb:Erweiterte Genauigkeit...
[attachment=56919:Unbenann...11_33_03.png]
funzt/funzt nicht?
Gruß SeBa
Funktioniert leider nicht, das habe ich auch schon ausprobiert. Bei Dir scheint es ja merkwürdigerweise zu funktionieren.
Testweise hatte ich mal das Selbe programmiert, bekomme aber den gleichen Fehler wie vorher.
Numerische Operationen für Gleitkommazahlen sind in einem Computer NIE genau! Es wird immer einen Fehler geben.
Ein grundsätzliches Problem ist z.B. das Addieren von einer "sehr großen" und einer "sehr kleinen" Zahl.
Oder vielfaches Addieren ein- und derselben Zahlen, da sich dort die Rundungsfehler addieren.
Ist so, war schon immer so, wird wahrscheinlich auch noch länger so bleiben.
Gruß, Jens
Da gibt es kein Weg dran vorbei? Es wird doch fast alles mit Computern berechnet, das kann ich mir nicht vorstellen. Taschenrechner bekommen es doch auch hin, es muss dazu doch eine Lösung in LabView geben
Das ist ja der Link, den ich auch schon in meinem Ausgangsposting angegeben habe. Leider existieren, die dort erwähnten dezimalen Datentypen, die das Problem umgehen sollen nicht in LabView oder ich bin zu doof sie zu finden.
' schrieb:Es gibt ja auch das neue Format "Festkomma" (FXP). Wer also seine Milliarden-Transaktionen auf dem Finanzmarkt immer auf den letzten Pfennig genau berechnen will und dazu Labview verwendet - mit diesem Formt liegt er richtig.
Bei Gleitkommazahlen muß die Frage, ob 0.1 + 0.2 = 0.3 ist, unter Berücksichtigung der Maschinentoleranz gestellt werden. Dann kommt duchaus ein "Ja" heraus - es ist aber umständlich immer so zu fragen:
[attachment=56934:clip.png]
Das FXP Format hatte ich mir auch angesehen, aber das löst mein Problem leider auch nicht. Den Vergleich kann ich leider schlecht machen, da ich ja nicht weiß was für eine Zahl rauskommt, das soll ja berechnet werden.
26.07.2010, 12:11 (Dieser Beitrag wurde zuletzt bearbeitet: 26.07.2010 12:27 von GerdW.)
"Ich vergleiche die Zahlen nicht, aber ich muss eine sehr kleine Kommazahl und eine kleine Kommazahl addieren."
Um welche Werte (Größenordnungen) handelt es sich denn? Bisher hast du nur von 0.1 und 0.2 geschrieben...
Grundproblem:
Die Floatingpoint-Zahlen haben jeweils nur eine bestimmte Genauigkeit. Die beträgt bei DBL z.B. 53 bit oder auch ~16 Dezimalstellen. Liegen deine "sehr kleine" und "kleine" Zahl also 16 Zehnerpotenzen auseinander, gibt's Probleme (Rundungsfehler)...
"Leider existieren, die dort erwähnten dezimalen Datentypen, die das Problem umgehen sollen nicht in LabView oder ich bin zu doof sie zu finden."
Kennst du eine andere Programmiersprache, die diese dezimalen Datentypen von Haus aus unterstützt? Einen relativ neuen Standard, der bisher noch nicht von Hardware (d.h. CPU-Befehlen) unterstützt wird?
Alternativ kannst du ja Bibliotheken zum Rechnen mit "unbegrenzter" Genauigkeit einbinden. Der Aufwand dafür könnte aber erheblich sein...
Edit:
Nachtrag zu den CPU-Befehlen: beim 6502 konnte man in einen Dezimalmodus umschalten und dann "normale" Rechenbefehle (ADD, SUB) benutzen. Beim 68k gab's die ABCD/SBCD-Befehle zum Rechnen mit BinaryCodedDecimals. Kannst du natürlich in LabVIEW nachbauen - haben andere Leute mit den o.a. Bibliotheken ja auch schon gemacht...
' schrieb:Funktioniert leider nicht, das habe ich auch schon ausprobiert. Bei Dir scheint es ja merkwürdigerweise zu funktionieren.
Testweise hatte ich mal das Selbe programmiert, bekomme aber den gleichen Fehler wie vorher.
Hast du auch alle Controlls neu erstellt oder nur die Darstellungsart auf EXT geändert? Das hat bei mir auch nicht funktioniert... also einfach mal frische EXT Controlls ins BD ziehen.
Gruß SeBa
Dieser Beitrag soll weder nützlich, informativ noch lesbar sein.
Er erhebt lediglich den Anspruch dort wo er ungenau ist, wenigstens eindeutig ungenau zu sein.
In Fällen größerer Abweichungen ist es immer der Leser, der sich geirrt hat.
Rette einen Baum!
Diesen Beitrag nur ausdrucken, wenn unbedingt nötig!
