LabVIEWForum.de

Ich arbeit seit einer Zeit an einem Programm und hab im Laufe der Programmierung Unregelmäßigkeiten mit Vergleichsoperatoren entdeckt die absolut nicht logisch sind!!!

Um das zu verdeutlichen habe ich ein kleines Beispiel-VI "Para2.vi" erstellt und dazu ein kurzes Video http://screenr.com/Svm aufgenommen.
Bitte schaut euch das an oder testet das VI, oder programmiert es halt nach ...
Ich weiß jetzt leider noch nicht ob nur mein System davon betroffen ist oder ob dieser Bug allgemein ist.

Das Beispiel-VI soll die While-Schleife, bei einem Wert der größer ist als die Eingabe (x), stoppen. Die Schrittweite kann dazu eingestellt werden, denn mit jedem Schleifendurchlauf wird zum Startwert Null die Schrittweite dazu addiert und danach an einen Schieberegister übergeben. Und wie gesagt, davor erfolgt die Abfrage mit einem Vergleichsoperator! Ich hab hier als Beispiel den "größer"-Vergleichsoperator gewählt. ... Wenn also der neu berechnete Wert größer als x ist, dann soll die Schleife gestoppt werden, und genau hier kommen die Bugs!!! Denn bei bestimmten Werten für x und für die Schrittweite kommt es vor, dass bei einem "gleichen" Wert die Abfrage als "true" ausgewertet wird. Statt ">" gilt also bei bestimmten Werten ">=". usw....

Aber dieser Bug ist auch bei anderen Vergleichsoperationen da, guckt euch das Video einfach mal an!

Ich hab vorhin sogar einmal LabVIEW 2009 mit der eingebauten Funktion (beim Deinstallieren/Installieren) "reparieren" lassen und danach noch den Patch f3 installiert, aber gebracht hat das nichts :-(

Lass dir mal den Wert "gestoppt bei: Wert > x" mit 25 Nachkommastellen anzeigen...dann siehst du schon, was los ist!

Berechnungen mit "Kommazahlen" sind in einem Computer nie 100% korrekt, da ergeben sich immer Rundungsfehler...das ist kein Bug, sondern systembedingt...weil dein Rechner nur mit Kombinationen von Einsen und Nullen arbeitet!

:verschoben12:aus Bugliste, da KEIN Bug.

Gruß, Jens

Ich denke das Problem ist, das du den Addierten Wert ausgibst, der ist immer letzter Wert+Schrittweite.
Du solltest den Wert für gestoppt, vor der Addition aus der Schleife führen.

Edit: und ein Video zum Fehler zeigen, ist ja was ganz neues-> Luxus pur

' schrieb:Lass dir mal den Wert "gestoppt bei: Wert > x" mit 25 Nachkommastellen anzeigen...dann siehst du schon, was los ist!

Berechnungen mit "Kommazahlen" sind in einem Computer nie 100% korrekt, da ergeben sich immer Rundungsfehler...das ist kein Bug, sondern systembedingt...weil dein Rechner nur mit Kombinationen von Einsen und Nullen arbeitet!

Hmmmm ... das ist sehr komisch ...
Immerhin gibt das VI (in meinem kleinen Testbereich mit max 2-4 Nachkommastellen) die Werte im Array und im Anzeigelement richtig gerundet aus. Aber der berechneten Wert ist dann also (im Nanobereich) schon größer

' schrieb:Immerhin gibt das VI (in meinem kleinen Testbereich mit max 2-4 Nachkommastellen) die Werte im Array und im Anzeigelement richtig gerundet aus. Aber der berechneten Wert ist dann also (im Nanobereich) schon größer

DBL-Werte, im allgemeinen Werte von Gleitkommazahlen, die man am Frontpanel sieht, sind für mathematische wie für Vergleichsoperationen immer irrelevant - sag ich jetzt so. Besonders dann, wenn die Anzeige auf 5 Stellen beschränkt ist. Gerechnet wird immer mit 19 Stellen (respektive so vielen wie der Typ (sgl, dbl, ext etc.) angibt. Man muss zwischen der Anzeige, die man sieht, und dem im Speicher hinterlegten Wert, mit dem gerechnet wird, unterscheiden.

' schrieb:Hmmmm ... das ist sehr komisch ...

Überhaupt nicht komisch!

Lektüre:
http://de.wikipedia.org/wiki/Gleitkommazahl
http://de.wikipedia.org/wiki/IEEE_754

Wenn man weiß, dass eine Gleitkommazahl intern in einem Computer immer irgendwas der Art a*2^(b) ist, dann wird es vielleicht klarer. Daraus folgt z.B. dass 0,1 nicht exakt als Gleitkommazahl dargestellt werden kann, aber z.B. 0,5 oder 0,25 schon.

Zusätzlich kommen dann noch Rundungsfehler beim Addieren hinzu.

Gruß, Jens

Mir ist gerade ne primitive, aber doch effektive Lösung als ich dachte eingefallen!

Da mein Wertebereich zurzeit max. 2 Nachkommastellen verlang, lass ich in der Schleife zuerst eine Multiplikation mit 100 durchführen, dann konvertiere ich den aktuellen Wert in einen LongInteger und führe anschließend eine Division mit 100 durch ... und tada !!! Das VI macht das, was es machen soll

[attachment=27495]

gelöscht

' schrieb:Da mein Wertebereich zurzeit max. 2 Nachkommastellen verlang, lass ich in der Schleife zuerst eine Multiplikation mit 100 durchführen, dann konvertiere ich den aktuellen Wert in einen LongInteger und führe anschließend eine Division mit 100 durch ... und tada !!! Das VI macht das, was es machen soll

Wie wär's denn, statt dbl i32 zu verwenden. Ganzzahlen haben von Natur aus keine Rundungsfehler.