Probleme mit Vergleichsoperation "kleiner gleich"

Hallo Leute!

bin soeben auf ein Problem im Zusammenhang mit der "kleiner gleich" Operation gestoßen.
Ich möchte Messwerte mit deren Sollwerten unter Berücksichtigung einer max. Toleranz
vergleichen.
Bei gewissen Abweichungen, z.B. 0,3 wird der Vergleich "Abweichung kleiner gleich Toleranz" als false
ausgewertet! (0,3 kleiner gleich 0,3 ergibt false!!!!)

Verwende die Basisversion LabVIEW 8.5, VI zum testen im Anhang zu finden!!
Hat jemand eine idee woran das liegen könnte????

Wenn ich die Mess- und Sollwerte nicht übers Frontpanel eingebe, sondern im Programm mit Konstanten
den Vergleich mache, klappt es!
Aber in meinem richtigen Programm werden die Mess- und Sollwerte aus Dateien eingelesen, was ja
auch einer Eingabe entspricht.
Der Vergleich mit den Konstanten diente nur zum Testen.

Könnte es an rundungsfehlern liegen wenn das Doubleformat 0,3 binär für die ALU codiert wird?

Viele Grüße,
Sebby


  Vergleich_2.vi (Größe: 9,9 KB / Downloads: 351)

Anzeige

' schrieb:Hat jemand eine idee woran das liegen könnte????

An der Ungenauigkeit der DBL/SGL-Zahlen. Mach dich mal z.B. bei Wikipedia schlau über Gleitkommazahlen etc.

Ein Wert, der in der Anzeige 0,3 anzeigt, kann tatsächlich bei 0,30000000000000001 liegen. Und damit ist er nicht kleiner gleich. Mit "gleich" zu arbeiten bei Gleitkommazahlen ist immer schlecht.

Danke!

Sowas hatte ich mir schon gedacht.
das liegt dann wohl an der ungenauigkeit, da eine double zahl ja binär max. aus 8 byte (64 bit)
dargestellt werden kann, und daher die nachkommastelle(n) nicht immer exakt dargestellt werden kann.

Du kannst das was IchSelbst sagt direkt sehen. Dazu Anzahl der signifikanten Stellen in Deinen Elementen auf 18 setzen.

Danke Lucki!

Gibt es denn die Möglichkeit dem LV mitzuteilen, dass intern im Kern alle Werte z.B.
auf 6 Nachkommastellen gerundet werden?!?

' schrieb:Gibt es denn die Möglichkeit dem LV mitzuteilen, dass intern im Kern alle Werte z.B.
auf 6 Nachkommastellen gerundet werden?!?

Das einzige was mir dazu einfällt ist ein neues Datenformat, welches ich erst kürzlich entdeckt habe. Keine Ahnung, ob es das erst seit 8.5 gibt - machmal sieht man ja den Wald vor Bäumen nicht. Ein Hilfe dazu habe ich auch noch nicht gefunden.
Es handelt sich um das Format FIX. Es ist ein Zahl mit Komma, nur der Unterschied zu DBL ist, daß sie intern nicht mit Mantisse und Exponent, sondern als Integer gespeichert ist.
Damit dürften solche "Rundungseffekte ohne sichtbaren Grund" nicht auftreten dürfen. Ausnahme natürlich Divisionsoperationen, die nicht aufgehen.
Habe Dein VI mal umgestelt auf 6 Kommastellen. Keine Ahnung, warum der Konvertierungspunkt erscheint. Weiß das jemand?
Das Ganze funktioniert natürlich nur, wenn der Wertebereich unter Kontrolle ist. Man kann mit FIX nicht mit den Zehnerpotenzen beliebig herumspringen.

  Vergleich_2_1_.vi (Größe: 12,31 KB / Downloads: 273)

Anzeige

Den maximalen Rundungsfehler kann man über Machine Epsilon ausrechnen. Danach kannst du den Fehler zu der zuvergleichenden Zahl addieren und damit vergleichen.

Die Maschinengenauigkeit ist ein Konstante. Hier die Anwendung. Bei Abfrage auf Gleichheit sollte die Alternative ganz oben verwendet werden. Bei Funktionen wie <= usw. wird aber der Vergleich durch Addieren oder Subtrahieren mit Epsilon nicht besser, die Schwelle verlagert sich nur in eine andere Richtung auf einen mindestens eben so "falschen" Wert. Aber in Deinem Beispiel - s.unten - bringt das Hinzufügen von Epsilon zur Toleranz ein Ergebnis, welche Du erwartest und welches Dich zufriedenstellt.
   
Es ist übrigens sehr schade, daß diese polyomorphe Funktion "Gleich?" im Falle eines Gleitkommavergleichs nicht grundsätzlioch als "Gleich innerhalb der Toleranz +-Epsilon?" realisiert ist, dann gäbe es das ganze Problem überhaupt nicht.

Danke, habe auch schon in diese richtung gedacht und werte in der größenordung von E-14
zur toleranz addiert, aber mit der maschinengenauigkeit habe ich jetzt einen festen wert.

' schrieb:Es handelt sich um das Format FIX. Es ist ein Zahl mit Komma, nur der Unterschied zu DBL ist, daß sie intern nicht mit Mantisse und Exponent, sondern als Integer gespeichert ist.

Int64?

Schau mal her. Gibts in Delphi schon seit Jahren. Heißt dort Currency. Ist für kaufmänniche Berechnungen. Dass es keine Rundungsfehler gibt.