+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Ungenauigkeit von Floatingpoint (allgemein) (/Thread-Ungenauigkeit-von-Floatingpoint-allgemein)
Seiten: 1 2
Ungenauigkeit von Floatingpoint (allgemein) - eMKay - 26.07.2010 12:51
' schrieb:Hallo eMKay,
"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...
Ich addierte Zahlen im Bereich von 0,0001 bis 1 und Zahlen von 7,7973687345558207E-18 bis 9,9999999999985964E-5 (direkt aus Labview kopiert). Ich hatte das Beispiel mit 0,1 und 0,2 nur verwendet um mein Problem auf einer sehr einfachen Ebene zu veranschaulichen.
Meine Zahlen liegen in der Tat weit auseinander.
Ich wusste nicht, dass diese dezimalen Datentypen nicht von Hardware unterstützt werden. Ich hatte mich nur auf den Artikel auf der oben genannten Webseite bezogen.
' schrieb:s. Gerd
DOCH, dem IST so!!!
Dieser Vergleich hinkt bzw. ist nicht zulässig. Ein Taschenrechner rechnet anders als eine FPU eines Computers.
http://www.wer-weiss-was.de/theme50/article2510135.html
Gruß, Jens
Faszinierend. Ich war mit nicht bewusst, dass eigentlch jeder ohne es zu wissen ständig ungenau rechnet. Danke für den Link mit dem Taschenrechner.
' schrieb: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
Ich habe alles neu erstellt. Der Unterschied ist, dass ich unter den Anzeigeformat auf "signifikante stellen" umgestellt habe und du auf "kommastellen". Wenn ich es auf Kommastellen einstelle bekomme ich auch den exakten Wert 0,300000000.. Wenn du es auf "sigifikante Stellen"umstellst wirst du sehen, dass du auch so einen "murks" rausbekommst wie ich.
Ungenauigkeit von Floatingpoint (allgemein) - GerdW - 26.07.2010 13:02
Hallo eMKay,
"Ich addierte Zahlen im Bereich von 0,0001 bis 1 und Zahlen von 7,7973687345558207E-18 bis 9,9999999999985964E-5"
EXT benutzen 64bit oder ~19 Dezimalstellen!
Schauen wir uns das mal an:
+0.000 100 000 000 000 000 000 000 000 000 000 0 (erste Zahl, abgesehen von Rundungsfehlern aufgrund unendlichem binären Bruch!)
+0.000 000 000 000 000 007 797 368 734 555 820 7 (zweite, sehr kleine Zahl)
=0.000 100 000 000 000 007 797 368 734 555 820 7 (Summe, "von Hand")
=0.000 100 000 000 000 007 797 4 (Summe, als EXT-Zahl, durch mich gerundet)
Problem erkannt? Dir fehlen plötzlich 12 Stellen im Ergebnis...
Ungenauigkeit von Floatingpoint (allgemein) - eMKay - 26.07.2010 13:19
Hi Gerd,
Ja das Problem habe ich erkannt
. Erschwerend zu den Fehlenden 12 Nachkommastellen kommt eben dieser Rundungsfehler hinzu. Der Ist in dem Moment ein größeres Problem als die fehlenden Stellen, da der Fehler an einer Stelle mit wesentlich höherer Signifikanz auftritt. Den fehlenden Kommastellen könnte ich ja zu Leibe rücken in dem ich (wie hier schon vorgeschlagen wurde) mit 10^x multipliziere, aber wenn der Rundungsfehler so "hoch" ist bringt mir das ja nichts, da ich den wieder reinbekomme sowie ich zurück in die Kommazahl umwandle.
Ungenauigkeit von Floatingpoint (allgemein) - rolfk - 17.08.2010 10:44
' schrieb: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
EXT löst das Problem nicht sondern vrschiebt es nur einige wenige Dezimalstellen nach hinten (und das auch nur auf Intel CPU Architekturen da das dem interenen FPU Zahlenformat entspricht, aber mit aktuellen LabVIEW Versionen ist alles gegenwärtig Intel CPU).
Die einzige wirkliche Lösung für dieses Problem ist eine Dezimalzahlrechnungsbibliothek zu machen. Das ist aber eine im Vergleich zu Floatingpointarithmetik mit eingebauter FPU-Unterstützung extrem langsame Berechnungsart. Greg McKaskle, einer der LabVIEW Programmierer der bis vor einigen Jahren ziemlich aktiv war in LabVIEW Foren hat mal so eine Library programmiert und verfügbar gemacht. Sie beruhte auf BCD Berechnungen und verwendete Strings um eine theoretisch unendliche Genauigkeit zu erreichen.
Für gewisse finanzielle Anwendungen manchmal unverzichtbar, aber sehr langsam und in vielen Dingen ziemlich unschön in der Verwendung da ein String natürlich alles beinhalten kann, nicht nur Zahlen, und die Library deshalb auch dass noch berücksichtigen muss.
' schrieb:Hallo eMKay,
"Ich addierte Zahlen im Bereich von 0,0001 bis 1 und Zahlen von 7,7973687345558207E-18 bis 9,9999999999985964E-5"
EXT benutzen 64bit oder ~19 Dezimalstellen!
Das stimmt so nicht ganz. LabVIEW Single Precision ist 4 Byte = 32 Bit (24 Bit Significand = ~8 digits), Double Precision ist 8 Byte oder 64 Bits (53 Bit Signifikant = ~15 digits) und Extended Precision ist 10 Bytes oder 80 Bits (64 Bit Signifikant = ~ 19 digits). Zwar verwendet LabVIEW 16 Bytes oder 128 Bits um eine Extended Precision Zahl in einem Flattened Format abzuspeichern das kommt aber daher dass in uralten Zeiten als LabVIEW auch noch auf Sun Sparc Stations lief, Gebrauch gemacht wurde von der Sun Software Mathematikbibliothek die eben ein 16 Byte Extended Format kannte.
Ungenauigkeit von Floatingpoint (allgemein) - GerdW - 17.08.2010 10:50
Hallo Rolf,
hast du einen Link auf diese Library?
Bin gerade an etwas ähnlichem dran, um mein Mandelbrot-VI für höhere Zoomstufen aufzubohren...
Ungenauigkeit von Floatingpoint (allgemein) - rolfk - 17.08.2010 11:13
' schrieb:Hallo Rolf,
hast du einen Link auf diese Library?
Bin gerade an etwas ähnlichem dran, um mein Mandelbrot-VI für höhere Zoomstufen aufzubohren...
So auf die Schnelle nicht. Das war eine Diskussion auf der Info-LabVIEW Mailingliste ziemlich sicher mindestens 10 Jahre her.