Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
30.06.2010, 22:31 (Dieser Beitrag wurde zuletzt bearbeitet: 01.07.2010 07:55 von jg.)
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 :-(
01.07.2010, 06:31 (Dieser Beitrag wurde zuletzt bearbeitet: 01.07.2010 06:33 von Achim.)
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!
"Is there some mightier sage, of whom we have yet to learn?"
"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
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
.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
' 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.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
01.07.2010, 09:27 (Dieser Beitrag wurde zuletzt bearbeitet: 01.07.2010 19:52 von jg.)
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
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
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
01.07.2010, 09:41 (Dieser Beitrag wurde zuletzt bearbeitet: 01.07.2010 09:45 von RoLe.)
' 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.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
