Moin zusammen,
es geistert hier immer wieder durch die Lande, das der EibPC Bugs bei f16 hat. Das mag vielleicht stimmen. Zuvor hier jedoch einige Überlegungen (deren Tatsachen bzgl. EibPC ggf. durch Enertex bestätigt werden müssen):
These
Der EibPC arbeitet intern mit einem f16 der sich exakt so verhält, wie ein "KNX Datapoint Type 9 “2-Octet Float Value”. Das bedeutet, wir haben es mit einer Gleitkommazahldarstellung derart zu tun, das
MEEEEMMM MMMM MMMM
E = [0 … 15] der Exponent zur Basis 2
M = [-2 048 … 2 047] die Mantisse in der Zweierkomplementdarstellung
Wertebereich ist [-671 088,64 … 670 760,96]
Die Interpretation ist so zu verstehen, das die Mantisse per se eine Auflösung von 0,01 besitzt.
Beispiel:
2.00f16 => 200 dezimal codiert => hex c8 00 = 0000 0000 1100 1000
oder auch:
20.47f16 => 2047 dezimal codiert => hex fe 07 = 0000 0111 1111 1111
wie zu sehen ist, ist jetzt die Mantisse "voll". Will man eine Zahl darstellen, die größer ist, so wird das nur funktionieren, wenn man den Exponent > 0 wählt.
Es gilt für FloatValue = (0,01*M)*2^E
Wollen wir beispielsweise ermitteln, welche Codierung sich für unseren Dezimal 85° Fehlerwert bei DS18B20 1Wire Sensoren ergibt so folgt:
85 / 2^E / 0,01 = M wobei E so zu wählen ist, das M im Bereich -2048 ... 2047 landet.
Wir wählen E mal mit 3 so ergibt sich
85 / 8 / 0,01 = 1062,5 gerundet 1063
zurückgerechnet in die Anzeige im Debugger etc. dann:
FloatValue = (0,01*1063)*2^3 = 85,04
Conclusio:
Für alle Werte mit einer Präzision die 0,01 bei einem Wertebereich -2048..2047 dezimalcodiert überschreiten muß ein anderer Datentyp verwendet werden.
Folgerung im Speziellen für die Implementation im Enertex EibPC:
Die Darstellung im Graphenbereich sollte durch f32 abgedeckt werden damit wir unsere schönen Dezimalnullen nicht mit Präzisionsproblemen krumm machen.
Gruß,
Bernd
es geistert hier immer wieder durch die Lande, das der EibPC Bugs bei f16 hat. Das mag vielleicht stimmen. Zuvor hier jedoch einige Überlegungen (deren Tatsachen bzgl. EibPC ggf. durch Enertex bestätigt werden müssen):
These
Der EibPC arbeitet intern mit einem f16 der sich exakt so verhält, wie ein "KNX Datapoint Type 9 “2-Octet Float Value”. Das bedeutet, wir haben es mit einer Gleitkommazahldarstellung derart zu tun, das
MEEEEMMM MMMM MMMM
E = [0 … 15] der Exponent zur Basis 2
M = [-2 048 … 2 047] die Mantisse in der Zweierkomplementdarstellung
Wertebereich ist [-671 088,64 … 670 760,96]
Die Interpretation ist so zu verstehen, das die Mantisse per se eine Auflösung von 0,01 besitzt.
Beispiel:
2.00f16 => 200 dezimal codiert => hex c8 00 = 0000 0000 1100 1000
oder auch:
20.47f16 => 2047 dezimal codiert => hex fe 07 = 0000 0111 1111 1111
wie zu sehen ist, ist jetzt die Mantisse "voll". Will man eine Zahl darstellen, die größer ist, so wird das nur funktionieren, wenn man den Exponent > 0 wählt.
Es gilt für FloatValue = (0,01*M)*2^E
Wollen wir beispielsweise ermitteln, welche Codierung sich für unseren Dezimal 85° Fehlerwert bei DS18B20 1Wire Sensoren ergibt so folgt:
85 / 2^E / 0,01 = M wobei E so zu wählen ist, das M im Bereich -2048 ... 2047 landet.
Wir wählen E mal mit 3 so ergibt sich
85 / 8 / 0,01 = 1062,5 gerundet 1063
zurückgerechnet in die Anzeige im Debugger etc. dann:
FloatValue = (0,01*1063)*2^3 = 85,04
Conclusio:
Für alle Werte mit einer Präzision die 0,01 bei einem Wertebereich -2048..2047 dezimalcodiert überschreiten muß ein anderer Datentyp verwendet werden.
Folgerung im Speziellen für die Implementation im Enertex EibPC:
Die Darstellung im Graphenbereich sollte durch f32 abgedeckt werden damit wir unsere schönen Dezimalnullen nicht mit Präzisionsproblemen krumm machen.
Gruß,
Bernd
Kommentar