' 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.
