TIA Hex Wert in Real Holding Register abfangen

Zuletzt bearbeitet:
Würde der Vergleich bei NaN False ergeben?
Gibt es vielleicht noch weitere Bitmuster, die NaN sind, und ergibt deren Vergleich mit NaN "gleich" :unsure:

Fressen Adler Fliegen?

Ich will mich ja nicht zu weit aus dem Fenster lehnen, aber der Vergleich des Wertes mit sich selbst ist meines Wissens ein gängiges Verfahren in so ziemlich allen Programmiersprachen. Ich habe es selber auch schon in Step7 genutzt, nach dem durch dreierlei Umständen ein NaN rekursiv entstanden war (neg. Wert durch Offset, Quadratwurzel, Rekursion durch Dämpfung). Ich glaube, über dieses Thema hatte ich irgend wann auch schon berichtet.
 
Zuletzt bearbeitet:
der Vergleich des Wertes mit sich selbst ist meines Wissens ein gängiges Verfahren in so ziemlich allen Programmiersprachen.
Jep, Wikipedia: NaN sagt das auch:
Da NaNs die einzigen Zahlen
x
sind, bei denen der Vergleich
x\neq x
wahr ist, kann man auch diesen Vergleich zur Erkennung von NaNs verwenden.

Gibt es vielleicht noch weitere Bitmuster, die NaN sind,
ja, alle diese Bitmuster:
16#7F80_0001 .. 16#7FFF_FFFF (sind quasi +NaN)
16#FF80_0001 .. 16#FFFF_FFFF (sind quasi -NaN)

und ergibt deren Vergleich mit NaN "gleich" :unsure:
nein, jeder Vergleich mit irgendeiner NaN ergibt "ungleich"

TIA SCL verwendet genau wie Fronius den Wert 16#7FC0_0000 als NaN-Kennzeichen, wenn eine mathematische Funktion einen ungültigen Real-Wert ergeben hat. Warum eigentlich genau dieser Wert?
EDIT: War es einfach der erstbeste (kleinste mögliche) Wert für Quiet NaN und hat sich als Quasi-Standard durchgesetzt, oder ist der Wert tatsächlich irgendwo festgelegt?

Harald
 
Zuletzt bearbeitet:
Zurück
Oben