Kleiner/gleich vergleich versagt

Guten morgen

In einem Teil meines Programms, wo 2 Werte verglichen werden, soll auch ein True ausgegeben werden, wenn die 2 Werte gleich sind. Normalerweise funktioniert der Vergleich immer prima, aber bei meinem Aufbau versagt er. Warum? Was mache ich da falsch? Sobald ich eine Zahl um 0,1 jeden Schleifendurchgang aufsteigen lasse und die andere Zahl 2 beträgt, erhalte ich ein False!

Hier mal ein Nachbau im Anhang. Handelt es sich um ein Formatierungsproblem?





  kleiner_gleich.vi (Größe: 10,2 KB / Downloads: 337)

Anzeige

Seltsam...wenn man als Startwert irgendwas kleiner als 1,7 eingibt ergibt sich das von dir beschriebene Verhalten, ab 1,8 stimmts...

Der Vergleich von Realzahlen auf Gleichheit funktioniert nur selten. Sie sind (- bei unterschiedlichen Rechenoperatinen -) nie gleich, sondern immer nur gleich innerhalb der Maschinengenauigkeit epsilon. Diese Konstante (siehe in der Funktionspalette unter numerisch) hat für double den Wert 2.22E-16. Wahrscheinlich kann bei mehreren Rechenoperationen hintereinander die resultierende Toleranz auch größer sein als Epsilon. Man sollte also, wenn es darauf ankommt, die Gleichheitprüfung durch die Prüfung, ob sie innerhalb der Toleranz Epsilon gleich sein, ersetzen.
Konkret: Die Zahl, die Du mit 2 vergleichst, hat in Wirklichkeit diesen Wert: (uups, das ist nicht die 2, aber Du verstehst schon)
   

Zitat:In einem Teil meines Programms, wo 2 Werte verglichen werden,

Mein Deutschlehrer hätte verzweifelt gerufen "Wo nur bei Ortsangaben, wie oft muß ich das noch sagen!"

edit: @Achim: ich würde das so erklären, daß Größe (und Vorzeichen) der Ungenauikeit abhängig von Startwert ist, so daß es bei einem Wert funktioniert, bei einem anderen nicht.

Das Vergleichen von Doubles wurde hier im Forum schon x-mal durchgekaut..., mann kann Doubles nicht direkt vergleichen.

Siehe hier: http://wiki.lavag.org/Numeric

VDB

edit: Lucki war schneller...

Oh, okay danke!
Trotzdem eine etwas verrückte Sache, dass man mit Hilfe der Genauigkeit/Formatierung diese Toleranz nicht wegfallen lassen kann...

Benutze statt dessen das VI "In Range and Coerce", da kannst du deine Toleranz wegfallen lassen.

Anzeige

' schrieb:Oh, okay danke!
Trotzdem eine etwas verrückte Sache, dass man mit Hilfe der Genauigkeit/Formatierung diese Toleranz nicht wegfallen lassen kann...

Das betrifft nur die Darstellung und hat keinen Einfluss auf den tatsächlichen Wert!

VDB

okay versuche es mal damit, sonst Vergleiche ich einfach ob es kleiner ist als der nächste Wert udn lasse eifnach das gleich weg, ich kenne ja die Schrittweite, da ich sie vorgebe.

Ist es möglich den Wert, den ich da Stück für Stück aufsummiere, näher an meinen eigentlichen Wert ranzubringen, oder lässt sich diese Toleranz nicht so leicht entfernen? ich gebe diese Wert nämlich an ein SourceMeter weiter, das die entsprechende Spannung/Strom erstellen soll dun will nicht das diese Toleranz bei größeren Messungen Einfluss nimmt.

' schrieb:Benutze statt dessen das VI "In Range and Coerce", da kannst du deine Toleranz wegfallen lassen.

' schrieb:Trotzdem eine etwas verrückte Sache, dass man mit Hilfe der Genauigkeit/Formatierung diese Toleranz nicht wegfallen lassen kann...

Die Formatierung betrifft nur die Darstellung in der Anzeige. Um die Zahl selbst auf z.B. echt 4 Kommastellen zu runden, mußt Du sie mit 1e4 multiplizieren, auf Ganzzahl runden und dann wieder durch 1e4 dividieren. (oder alternativ: zwischenzeitlich in Text konvertieren).

... und diesmal war VDB schneller, ein Telefonanruf während des Schreibens (in offensichtlich bösartiger Absicht) war schuld!

Das mit dem String funktioniert einwandfrei, erst in String und dann wieder zurück nach DBL, dankeschön!
Für mich ist der Fall so erledigt, ich habe eine Lösung und bin ein ganzes Stück schlauer! Danke! ich werd wohl in Zukunft lieber alles nochmal selbst nachrechnen was eine Maschine mir ausspuckt

' schrieb:Die Formatierung betrifft nur die Darstellung in der Anzeige. Um die Zahl selbst auf z.B. echt 4 Kommastellen zu runden, mußt Du sie mit 1e4 multiplizieren, auf Ganzzahl runden und dann wieder durch 1e4 dividieren. (oder alternativ: zwischenzeitlich in Text konvertieren).

... und diesmal war VDB schneller, ein Telefonanruf während des Schreibens (in offensichtlich bösartiger Absicht) war schuld!