(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?
/
Flatten to xml -> Zahlen fehlerhaft
