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!
Ich habe folgendes Problem: in dem angehängten VI findet die "Suche-Schleife" den vorgegebenen Wert nicht, obwohl er in dem Array vorhanden ist! Wenn derselbe Wert "von Hand" nochmal selber eingegeben wird, funktioniert es - wieso?
Im vollständigen VI habe ich es so implementiert, dass man aus einer Textdatei, in der die Daten für ein Richtdiagramm stehen, auch immer nur die Frequenzen auswählen kann, die es auch gibt. Sprich das min, max und das Inkrement werden immer fest eingelesen. Das funktioniert auch, allerdings nur bis zu der Frequenz, die auch im angehängten VI als default eingestellt ist. Größere Frequenzen findet er dann auf einmal nicht mehr... (und ich wage zudem zu behaupten, dass das alles schon mal geklappt hat)
Nicht-Integer-Zahlen mit "=" zu suchen ist fast immer zum Scheitern verurteilt! Das liegt an Rundungsfehlern...du musst hier mit "in Range" oder ">=" arbeiten
A.
"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)
Danke für die schnelle Antwort. Eigentlich möchte ich auch nicht den "="-Operator verwenden (wenngleich ich bisher das Problem mit den nicht-Integer-Zahlen nicht kannte, also vielen Dank für den Hinweis), sondern den search-1D-array, der ja auch mit double-Werten klarkommen sollte?
Ich habe das "= " durch ein ">=" ersetzt und jetzt klappt es so wie ich wollte. Wenngleich ich mich immer noch wunder, was da vorher schief lief, hakt ich es einfach unter LV-Kuriosität ab. Vielen Dank nochmal für den Tipp
' schrieb:hakt ich es einfach unter LV-Kuriosität ab.
Was meinst du damit? Dass Vergleich mit '=' und 1D-DBL-Array-Durchsuchen nicht geht? Das ist keine Kuriosität von LV - das liegt in der Natur dieses Zahlentyps.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Nein, die Kuriosität ist die, dass der als default eingestellte Wert von 84,96 nicht geht - aber wenn ich 84,96 nochmal per Hand direkt eingebe, das Ganze also einfach nochmal überschreibe, klappt es.
' schrieb:Nein, die Kuriosität ist die, dass der als default eingestellte Wert von 84,96 nicht geht - aber wenn ich 84,96 nochmal per Hand direkt eingebe, das Ganze also einfach nochmal überschreibe, klappt es.
Auch das ist keine Kuriosität von LV.
Wenn du die Zahl 84,96 eingibst, dann ist diese Zahl auch 84,96. Wenn die Zahl z.B. durch eine mathematische Operation entstanden ist, dann wird sie möglicherweise nur gerundet dargestellt. z.B. mit 6 signifikanten Stellen. Tatsächlich ist diese Zahl möglicherweise aber 84,9600000000001283. Auch dieser Effekt fällt unter die Natur der Zahl - wenn auch nur deren Darstellung.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Auch das ist keine Kuriosität von LV.
Wenn du die Zahl 84,96 eingibst, dann ist diese Zahl auch 84,96. Wenn die Zahl z.B. durch eine mathematische Operation entstanden ist, dann wird sie möglicherweise nur gerundet dargestellt. z.B. mit 6 signifikanten Stellen. Tatsächlich ist diese Zahl möglicherweise aber 84,9600000000001283. Auch dieser Effekt fällt unter die Natur der Zahl - wenn auch nur deren Darstellung.
Das ist mir auch klar. Nur entsteht die Zahl bei mir durch das Einlesen aus einem String. Und bei der String-Zahl Konvertierung habe ich genau zwei Nachkommastellen als Genauigkeit. Oder kann dort, auch wenn man es anders angibt, eine "krumme" Zahl, wie Du sie als Beispiel hattest entstehen?
18.03.2009, 08:38 (Dieser Beitrag wurde zuletzt bearbeitet: 18.03.2009 08:39 von rolfk.)
' schrieb:Das ist mir auch klar. Nur entsteht die Zahl bei mir durch das Einlesen aus einem String. Und bei der String-Zahl Konvertierung habe ich genau zwei Nachkommastellen als Genauigkeit. Oder kann dort, auch wenn man es anders angibt, eine "krumme" Zahl, wie Du sie als Beispiel hattest entstehen?
Ja das kann! Um einen String in eine Zahl zu verwandeln muss man rechnen. Dezimalzahlen haben aber die unangenehme Eigenschaft dass sie die Basis 10 haben die sich leider im binären Format des Computers nicht exakt darstellen lässt, wenn man mit Nachkommastellen arbeitet. (Versuch mal 0.1 einzugeben und dann erweitere die Darstellung des Numeric Controls um 20 Stellen nach dem Komma zu zeigen!)
Also Du hast die Zahl 12.345 als String. Die String->Zahl Umwandlung macht dann ungefähr so etwas wie:
Das Ganze kann noch optimalisiert werden aber das Prinzip bleibt.
Es dürfte wohl deutlich sein dass bei solchen Berechnungen mit Fliesskommazahlen und Zahlen die nicht exakt Vielfache von 2 sind die Genauigkeit des Resultats "nur" im Rahmen der Basisgenauigkeit des Zahlentyps ist. Diese ist ungefähr 8 dezimale Stellen bei Single-Precision Floats und ungefähr 14 dezimale Stellen bei Double-Precision Floats.
Da hier niemend ein Beispiel bringt, hier mal zwei:
Beispiele untere Hälfte:
Die richtige Funktion ist nicht, wie Du sagtest, "Array Interpolieren", sondern "Schwellwert 1D Array". Damit erhält Du immer ein Ergebnis, solange das Element nicht außerhalb der Arrayelemente liegt.
(Du siehst hier auch, daß der interpolierte Index nicht genau 7 ist ind deshalb Dein VI nicht funktionieren konnte. Den gebrochenen Index kannst Du gegebenenfalls zu einer Ganzzahl runden)
Beispiele obere Hälfte: Dein VI modifiziert. Alle Elemente werden in Zahlenstrings mit einer definierbaren Genauigkeit (Anzahl Kommastellen) umgewandelt und das wird miteinander verglichen. Damit gibt es keine Probleme mehr mit der endlichen Maschinengenauigeit bei Zahlen.
