+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Datenbank & File IO (/Forum-Datenbank-File-IO)
+---- Thema: Flatten to xml -> Zahlen fehlerhaft (/Thread-Flatten-to-xml-Zahlen-fehlerhaft)
Flatten to xml -> Zahlen fehlerhaft - Hans lv-dau - 17.11.2011 15:10
Hallo,
bei der recht simplen Funktion flatten to xml gib es bei dbl-Werten >4224 einen "Rundungsfehler".
Gefunden bei LV-Version 8.6 und 2010 SP1, hier im Beispiel auf die Funktion reduziert, aufgefallen ist das weil natürlich der falsche Wert auch in der Datei landet.
Hat da jemand eine Erklärung?
Ist das "vermeidbar"?
Danke und Grüsse
Hans
RE: Flatten to xml -> Zahlen fehlerhaft - jg - 17.11.2011 15:46
Stell doch mal die Zahlenanzeige im FP auf "viele" (mind. 16) Nachkommastellen um und schau dir an, was für Werte da wirklich drinstehen.
Gruß, Jens
RE: Flatten to xml -> Zahlen fehlerhaft - Hans lv-dau - 17.11.2011 16:26
hier mal mit 16 Nachkommastellen.
und hier:
http://zone.ni.com/reference/en-XX/help/371361E-01/glang/flatten_to_xml/
habe ich das gefunden:
xml string is the resulting XML string that represents the LabVIEW data type. When converting decimal values, this function uses only the period (.) as a decimal separator. The function does not use localized decimal separators.
ganz dunkel ist da noch die Erinnerung an Auflösung, wie bei Filtern und Digitalisierung und dem verlorenen LSB ...
RE: Flatten to xml -> Zahlen fehlerhaft - Hans lv-dau - 18.11.2011 08:57
ich habe jetzt anstatt dem cluster mal nur einen string bzw. dbl-Wert zum xml:
numeric-Wert 4250.123456789123
ergibt diesen xml-string:
<DBL>
<Name>Numeric</Name>
<Val>4250.12345678912333</Val>
</DBL>
string-Wert 4250.123456789123
ergibt diesen xml-string:
<String>
<Name>String</Name>
<Val>4250.123456789123</Val>
</String>
numerische Werte werden "irgendwie" konvertiert und string geht direkt in xml-string!
wer kann denn sowas erklären?
RE: Flatten to xml -> Zahlen fehlerhaft - unicorn - 18.11.2011 10:31
Nummerische Werte werden mit maximaler Stellenanzahl formatiert als String ausgegeben. Da sieht man dass im Computer Fließkommazahlen diskret sind.
Da eine XML-Datei auch für Menschen lesbar sein soll, wird die Fließkommazahl nicht binär ausgegeben (dann würde Dir die Diskretisierung gar nicht auffallen) sondern als String formatiert. Und das mit voller Stellenzahl, damit beim Einlesen wieder die gleiche Zahl im Speicher steht.
Beim String gibt es nichts umzuwandeln. Der kann 1:1 ausgegeben werden.
Vielleicht hilft das hier noch weiter: http://de.wikipedia.org/wiki/Gleitkommazahl
RE: Flatten to xml -> Zahlen fehlerhaft - Hans lv-dau - 18.11.2011 14:10
Diskretisierung ist das Stichwort
Was ich aber nicht kapiere sind die Zusammenhänge:
-> warum schon so "früh", double sind doch 64bit?
die Beschreibungen der Begrenzungen zu Mantisse (11bit?) und Exponent (52bit?) liegen ja über 4225
-> warum bei 4225 und nicht z.B. bei 4096?
also was "binär nachvollziehbares"
RE: Flatten to xml -> Zahlen fehlerhaft - unicorn - 18.11.2011 21:58
Fließkommazahlen in binärer Computerdarstellung sehen immer so aus: 1,m * 2^e. m = Mantisse e = Exponent mit je nach Norm verschiedenen Anzahl von Ziffern. 4096 oder 4225 kommt nicht vor.
Im Dezimalsystem wär es so: 4,096 * 10^3, oder 1 * 10^1 oder ... Die Mantisse ist immer kleiner 10.
Der Diskretisierungsunterschied sollte bei vielen Zahlen auftreten.
RE: Flatten to xml -> Zahlen fehlerhaft - rolfk - 19.11.2011 21:33
(18.11.2011 14:10 )Hans lv-dau schrieb: Diskretisierung ist das Stichwort
Was ich aber nicht kapiere sind die Zusammenhänge:
-> warum schon so "früh", double sind doch 64bit?
die Beschreibungen der Begrenzungen zu Mantisse (11bit?) und Exponent (52bit?) liegen ja über 4225
-> warum bei 4225 und nicht z.B. bei 4096?
also was "binär nachvollziehbares"
4096 ist ganz zufällig 2^12 also ein genaues Vielfaches von 2 und deshalb im binären Zahlensystem exact darstellbar. 4225 halt nicht und deshalb wird im Computer die nächstgrössere oder kleinere im Speicher darstellbare Zahl verwendet. LabVIEW numerische Controls enthalten eine Logic, die die eingestellte Prezision benützt und das erste nicht mehr dargestellte Digit verwendet um auf- oder abzurunden.
4225 wird im Speicher effektiv als 4424.99999999999999 abgespeichert da das die der gewünschten Zahl am nächsten kommende mögliche Zahl ist bei einer Double Floating Point Zahl ist. Solange Du das FP Control weniger als 14 Dezimalstellen (oder ~18 Digits) darstellen lässt, wird LabVIEW dir immer 4425 darstellen. Im XML File wird die Double Zahl aber mit maximaler Genauigkeit ausgegeben, da LabVIEW nicht wissen kann ob Dir 1, 5, 10, oder 13 Dezimalstellen wichtig sind. Die einzige Art und Weise um die maximale Übereinstimmung zu garantieren ist um die Zahl mit maximaler Genauigkeit abzuspeichern. Wenn LabVIEW nur 4225 im XML File abspeichern würde, wäre die resultierende Zahl beim Einlesen dieses Files eben nicht wirklich gleich sondern nur ähnlich.
Und falls Du wirklich nur in 4225 interessiert bist solltest Du natürlich auch eine Integerzahl als Datentyp verwenden.
GrundsÄtzlich ist dazu zu sagen: Der Fehler den LabVIEW anscheineind macht ist eben kein Fehler sondern eben das Gegenteil davon. Du als Interpretator machst hier den grösseren Fehler und bemängelst schlichtweg das LabVIEW zu exact arbeitet. Lösungen sind verschiedene:
1) Den richtigen Datentypen verwenden, wie hier Integer wenn die Nachkommagenauigkeit nicht erwünscht ist.
2) Die Interpretationsroutine (auch in Deinen grauen Zellen) so anpassen dass eben eingesehen wird, dass dies kein wirklicher Fehler ist, sondern prinzipbedingt mit der endlichen Genauigkeit von Zahlen in Computern zu tun hat. Nur weil Du das Dezimalsystem gewöhnt bist heisst das nicht das 4225 immer genau 4225 ist. Umgekehrt könnte ein Computer auch reklamieren dass seine schönenen binären Fliesskommazahlen nicht immer genau in unserem dezimalen Zahlensystem darstellbar sind ohne unendlich viele Nachkommastellen zu verwenden.
3) Und zu guter Letzt, das bemängelte Problem ist effektiv keines. Solange Du nicht mit extremen mathematischen Modellen zu tun hast, ist die Ungenauigkeit beim Messen immer ganze Logarithmen grösser als diese Ungenauigkeit durch die eingeschränkte Darstellbarkeit von Zahlen ist. Kannst Du wirklich behaupten dass bei einer Messung 4225 der exaktere Messwert ist dann 4424.99999999999999?
RE: Flatten to xml -> Zahlen fehlerhaft - Hans lv-dau - 21.11.2011 08:47
ok!
Vielen Dank an Alle für die Erläuterungen