Kehrwertergebnis im Anzeigeelement fehlerhaft

Hallo LabVIEW-User,

bei der Berechnung eines Werts mit der Kehrwertfunktion ist mir aufgefallen, wenn
man die Darstellung des Anzeigeelements bei 14 Nachkommastellen einstellt, kommt
dabei keine Runde Zahl wie zu erwarten raus. Ist das ein Darstellungsfehler?

   

Hallo Labtron,

Zitat:bei der Berechnung eines Werts mit der Kehrwertfunktion ist mir aufgefallen, wenn man die Darstellung des Anzeigeelements bei 14 Nachkommastellen einstellt, kommt dabei keine Runde Zahl wie zu erwarten raus. Ist das ein Darstellungsfehler?

Nein, das ist kein Darstellungsfehler. Das ist wirklich der berechnete Wert - und der ist sogar korrekt berechnet!

Du bist gerade in die Falle getappt, die das Rechnen mit Float-Zahlen mitbringt. Diese sind nur "ungefähr", insbesondere bei Eingangswerten wie deinen.
Stell doch mal die Anzeige deines Inputs auf 14-17 Stellen um, dann wirst du sehen, dass du NICHT den Kehrwert von 0.0002=1/5000 berechnest…

Hallo GerdW,

hab den Eingang auf 20 Stellen umgestellt, und da zeigt es "0,00020000000000000001" an. Dann ist auch kein wunder, dass bei Double die eh nur ne 15 stellige Genauigkeit kann.
Jedoch stelle ich mir die Frage, wo die 1 herkommt, die ich ja nicht eingegeben habe. Das ganze ist mir nur aufgefallen, weil ich den ergebniswert in die Exceltabelle exportiert habe und dort
im Vergleich keine übereinstimmung gefunden habe. Dort zeigt es stramm die 5000 an, auch wenns 30 stellen hat.

Nachtrag: Habs nochmal probiert, den Eingangswert vorher zu runden. Trotzdem hauts am ende das gleiche Ergebnis wie vorher auch raus.

Hallo Labtron,

Zitat:Jedoch stelle ich mir die Frage, wo die 1 herkommt, die ich ja nicht eingegeben habe.

Ganz einfach:
FloatingPoint-Zahlen haben eine begrenzte Genauigkeit UND eine begrenzte Auflösung!
DBL-Zahlen haben 53bit Mantisse: die Auflösung ergibt sich damit zu 2^(exponent-53). (Vielleicht liege ich 1bit daneben mit der Formel, aber die Prinziprechnung bleibt.)

Und da Floats üblicherweise als Binärwerte kodiert werden, kommt noch hinzu, dass alle Brüche mit 10er Potenzen im Binärsystem unendliche Brüche sind! Damit können solche Werte, die im Dezimalsystem "glatte" Nachkommastellen haben, nicht exakt im Binärsystem dargestellt werden. Und deine 0.0002 sind eben 2*10^-4…
Runden der Floatzahl auf 5 Nachkommastellen ergibt so auch keinen Sinn: sobald du irgendwie wieder auf den Zahlenwert 0.0002 zurückrechnest (entweder durch Umwandeln eines Strings "0.0002" in eine Float-Zahl oder durch dividieren von 2 durch 10^4) bekommst du wieder einen Floatwert, der eben möglichst genau den Wert 0.0002 repräsentiert - aber eben nicht exakt!

Diese Rundungsproblematik findest du in vielen Threads hier im LabVIEW-Forum, im NI-Forum und in diversen anderen (Programmier-)Foren! Lies dir bitte die Grundlagen zu Floatzahlen durch…

Daraus ergeben sich Grundregeln im Umgang mit Floats:
- NIE auf Gleichheit prüfen (zumindest bei Rechenwerten)!
- Dran denken, dass es für den (gültigen!) Wert NaN ebenfalls klar definierte Rechenregeln gibt…

In der Zwischenzeit bin ich ja auch fündig geworden, auch über Deine Signatur hinterlegten Verweis auf das Dokument "floating_point_in_labview.pdf" gestossen. Deine
Antwort jetzt ist auch nochmal schön Zusammengefasst, danke dafür. Hab ja vorher schon per Google-Suche recherchieren wollen. Die Verweise auf ni.com sind durch das
neue Homepage von denen nutzlos geworden. Sie führen einfach ins Leere.

Jedefalls habe ich den vergleich einfach umgekehrt, und den ergebniswert aus Excel ins LabVIEW kopiert, und da der String eh noch in double formatiert werden musste, passte am Ende
auch wieder.

Sers...
Mir ist die ganze Thematik natürlich geläufig, und da fall ich nicht mehr drauf rein ;-)

Was ich mich aber schon oft gefragt hab: Was macht EXCEL anders? Sind die MS-Leute schlauer als alle anderen Menschen? Wie fangen die das Problem ab? Die haben doch die genau gleichen Speicher- und Darstellungs-Probleme...

Gruß
Achim

(20.05.2022 10:15 )Achim schrieb:  Was ich mich aber schon oft gefragt hab: Was macht EXCEL anders? Sind die MS-Leute schlauer als alle anderen Menschen? Wie fangen die das Problem ab? Die haben doch die genau gleichen Speicher- und Darstellungs-Probleme...

Ich vermute einfach mal, dass das bereits programmintern berücksichtigt wird. Wie GerdW schon darauf verweist, gehört diese Thematik auch zum Grundwissen der Programmierung. Wenn aber das grundlegend
bekannt ist, warum fügt NI nicht einfach eine weitere Vergleichsfunktion zur Palette hinzu. Im dem anderen Thread unter Beitrag Nr. 7 wird das auch gefragt.

L@BTR0N schrieb:Das ganze ist mir nur aufgefallen, weil ich den ergebniswert in die Exceltabelle exportiert habe ...

Excel nutze hab ich einfachshalber genommen, um z.B. Ergebniswerte eines Formelknotens nachprüfen zu können. Bei wenigen Nachkommastellen ist das auch nie das Thema gewesen. Dennoch unschön, wenn es schon durchs kopieren daran scheitert und zunächst erstmal ein Fehler in der Formel sucht.

Hallo Labtron,

Zitat:Wenn aber das grundlegend bekannt ist, warum fügt NI nicht einfach eine weitere Vergleichsfunktion zur Palette hinzu.

Weil NI die IEEE854-Standard-konformen Funktionen bereitstellt.

Wenn du einen "ungenauen" Vergleich machen willst, kannst du ihn dir einfach selbst programmieren und als subVI in deine user.lib einfügen.
(Dann hast du auch freie Hand, wie "ungenau" du auf Gleichheit prüfen willst…)

(20.05.2022 10:15 )Achim schrieb:  Was macht EXCEL anders? Sind die MS-Leute schlauer als alle anderen Menschen? Wie fangen die das Problem ab?

Nö, die sind nicht schlauer - nur genervt ....
Ich setze jetzt mal ein Gerücht in die Welt:
Der durchschnittliche Benutzer von Exel hat keine Ahnung von Floating-Point Zahlen und rennt damit immer wieder mal gegen die Wand und versteht die Welt nicht mehr. Das kann man dem auch nicht durch sachlich korrekte Erklärungen beibringen. Das nervt dann natürlich dann auch die Softwerker bei Microsoft, also haben sie das Problem einfach beseitigt indem vor der Darstellung passend gerundet wird.

Es lässt sich ja feststellen, wie viele Stellen eine Zahl hat, wenn in kauf genommen wird, dass es eine kleine Abweichung geben darf. Dann wird gerundet und alles ist gut. Zur Darstellung könnet auch einfach auf z.B. 13 Stellen gerundet werden.