Merkwürdiges Verhalten StateFormat

Begonnen von M_I_B, 31 März 2019, 15:25:38

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten1
Benutzer-Aktionen

M_I_B

31 März 2019, 15:25:38 Letzte Bearbeitung: 31 März 2019, 15:29:21 von M_I_B
Moin Kinnaz,

ich schreibe das mal hier, weil ich nicht genau weiß, wo es besser passen würde...
Ich hatte zu dem Thema im Zusammenhang schon mit Klaus W. (52_I2C_MCP342x.pm) Kontakt bezgl. einer anderen Sache damit...

Untenstehend mal das Listing...

Die Readings des Devices (ChannelX) bleiben so wie sie sind, da keine Hardware an den Eingängen angeschlossen (lediglich mit C's geblockt), Ebenso bleiben die Offset- korrigierten UserReadings alle brav bei "0"...

Aber: In den per "stateFormat ||| CH1 ||| CH2 ||| CH3 ||| CH4 |||" zusammengefassten Werten aus den UserReadings tauchen sporadisch auf beliebigen Kanälen Werte auf, die mit den Device- resp. UserReadings nichts zu tun haben.
Die meiste Zeit steht da ebenfalls vier mal eine "0". Dann aber, ohne erkennbaren Zusammenhang, taucht mal bei diesem, mal bei jedem Kanal ein Wert auf in der Form ...

   
||| -1.95400000000001 ||| 0 ||| 0 ||| 1.95400000000001 |||

Oft ist es genau dieser Wert "1.95400000000001", manchmal aber auch ein anderer Wert, immer aber dezimal zwischen -2 und +2.

Ich hatte jetzt auch schon die optischen Trennzeichen weggelassen oder andere Zeichen hergenommen, aber das ändert an dem Verhalten nichts.

Jemand eine glorreiche Idee, woher das kommt? Auf dem System läuft nur der AD und 1W, nichts weiter; keine DoIf's oder ähnliches... Vollkommen jungfräuliches System... (Hinweis: Pollintervall ist 30 Sekunden und nicht 30 Minuten auf Grund modifizierter pm)

Code Auswählen
Internals:
   CHANGED   
   DEF        0x69 4
   FUUID      5c97e9e8-f33f-5bb0-be14-6b415fe4ff1caaa3
   I2C1_SENDSTAT Ok
   I2C_Address 105
   IODev      I2C1
   NAME       AD.02
   NR         15
   STATE      ||| -1.95400000000001 ||| 0 ||| 0 ||| 0 |||
   TYPE       I2C_MCP342x
   channels   4
   .attraggr:
   .attreocr:
     Channel1
     Channel2
     Channel3
     Channel4
   .attrminint:
   .userReadings:
     HASH(0xe4aa08)
     HASH(0xeeff60)
     HASH(0xeee908)
     HASH(0xeefb88)
   READINGS:
     2019-03-31 15:24:26   CH1             -1.95400000000001
     2019-03-31 15:24:26   CH2             0
     2019-03-31 15:24:26   CH3             0
     2019-03-31 15:24:26   CH4             0
     2019-03-31 15:24:24   Channel1        -72.266
     2019-03-31 15:24:25   Channel2        -70.312
     2019-03-31 15:24:25   Channel3        -76.172
     2019-03-31 15:24:26   Channel4        -72.266
     2019-03-31 15:24:26   state           Ok
Attributes:
   IODev      I2C1
   ch1factor  1000000
   ch1gain    8
   ch1resolution 18
   ch1roundDecimal 3
   ch2factor  1000000
   ch2gain    8
   ch2resolution 18
   ch2roundDecimal 3
   ch3factor  1000000
   ch3gain    8
   ch3resolution 18
   ch3roundDecimal 3
   ch4factor  1000000
   ch4gain    8
   ch4resolution 18
   ch4roundDecimal 3
   event-on-change-reading Channel1,Channel2,Channel3,Channel4
   poll_interval 30
   room       Sensoren
   stateFormat ||| CH1 ||| CH2 ||| CH3 ||| CH4 |||
   userReadings CH1 { ReadingsVal("AD.02", "Channel1", "0") + 70.312 }, CH2 { ReadingsVal("AD.02", "Channel2", "0") + 70.312 },
CH3 { ReadingsVal("AD.02", "Channel3", "0") + 76.172 }, CH4 { ReadingsVal("AD.02", "Channel4", "0") + 72.266 }

Wzut

#1
31 März 2019, 15:39:25
Zitat von: M_I_B am 31 März 2019, 15:25:38
Ebenso bleiben die Offset- korrigierten UserReadings alle brav bei "0"...

Code Auswählen

   READINGS:
  2019-03-31 15:24:26   CH1             -1.95400000000001
 
sieht so eine brave 0 aus ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

M_I_B

#2
31 März 2019, 15:44:26
... ok, der ist jetzt neu und mir gerade gar nicht aufgefallen ...

Ich hatte ein Bildschirm- Video mitgeschnitten und da war es in allen Fällen so, das zumindest dort die UserReadings nicht betroffen waren...

Ok, also definiere ich das mal um: Manchmal sind die UserReadings betroffen, manchmal nicht.

Wzut

#3
31 März 2019, 15:48:14
glaube ich nicht.
da du eh schon event-on-change-reading für die Channels 1-4 drin hast würde ich mal die vier Readings in einem Filelog mitschreiben.
Nach deiner Therorie müsste das dann ja leer bleiben
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

M_I_B

#4
31 März 2019, 15:49:58
... gute Idee. Schmeiße ich gleich mal an und lasse es während meiner Abwesenheit laufen; muss gleich ein paar Stunden weg ...

Wzut

#5
31 März 2019, 15:52:11
ich wette das Log wird sich füllen , schau dir nochmal an was du gepostet hast :
Code Auswählen
Channel1        -72.266
der ist da ungleich Channel 2 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

M_I_B

#6
31 März 2019, 20:00:14 Letzte Bearbeitung: 31 März 2019, 20:09:43 von M_I_B
Zitatder ist da ungleich Channel 2 
... warum sollten die unbeding gleich sein? Das ist doch Bauteiltolleranzen und der hohen Verstärkung geschuldet. Das die teilweise auch um ein paar Hundertstel jittern, ist auch normal ...

Aber zum Thema:
Im Logfile sind keine Auffälligkeiten zu entdecken. Diese merkwürdigen Brüche im Nano- Bereich müssen daher m.E. irgendwo aus der Berechnung der UserReadings entstehen...

Edit: Habe noch mal ein Export nach Kanal sortiert als Bild angefügt

Code Auswählen
2019-03-31_16:00:38 AD.02 Channel4: -70.312
2019-03-31_16:01:41 AD.02 Channel4: -72.266
2019-03-31_16:04:50 AD.02 Channel1: -72.266
2019-03-31_16:05:22 AD.02 Channel1: -70.312
2019-03-31_16:08:00 AD.02 Channel1: -72.266
2019-03-31_16:08:01 AD.02 Channel4: -70.312
2019-03-31_16:08:32 AD.02 Channel1: -70.312
2019-03-31_16:09:36 AD.02 Channel4: -72.266
2019-03-31_16:10:38 AD.02 Channel1: -72.266
2019-03-31_16:11:10 AD.02 Channel1: -70.312
2019-03-31_16:11:42 AD.02 Channel2: -68.359
2019-03-31_16:11:43 AD.02 Channel4: -70.312
2019-03-31_16:12:14 AD.02 Channel2: -70.312
2019-03-31_16:12:46 AD.02 Channel4: -72.266
2019-03-31_16:13:49 AD.02 Channel4: -70.312
2019-03-31_16:14:21 AD.02 Channel4: -72.266
2019-03-31_16:16:27 AD.02 Channel4: -70.312
2019-03-31_16:16:59 AD.02 Channel4: -72.266
2019-03-31_16:24:21 AD.02 Channel1: -72.266
2019-03-31_16:24:52 AD.02 Channel1: -70.312
2019-03-31_16:28:34 AD.02 Channel1: -72.266
2019-03-31_16:29:06 AD.02 Channel1: -70.312
2019-03-31_16:30:41 AD.02 Channel1: -72.266
2019-03-31_16:31:12 AD.02 Channel1: -70.312
2019-03-31_16:31:44 AD.02 Channel1: -72.266
2019-03-31_16:31:45 AD.02 Channel4: -70.312
2019-03-31_16:32:15 AD.02 Channel1: -70.312
2019-03-31_16:32:17 AD.02 Channel4: -72.266
2019-03-31_16:34:54 AD.02 Channel1: -72.266
2019-03-31_16:34:55 AD.02 Channel4: -70.312
2019-03-31_16:35:27 AD.02 Channel4: -72.266
2019-03-31_16:35:57 AD.02 Channel1: -70.312
2019-03-31_16:38:36 AD.02 Channel4: -70.312
2019-03-31_16:39:08 AD.02 Channel4: -72.266
2019-03-31_16:39:39 AD.02 Channel2: -68.359
2019-03-31_16:40:10 AD.02 Channel2: -70.312
2019-03-31_16:41:45 AD.02 Channel1: -72.266
2019-03-31_16:42:17 AD.02 Channel1: -70.312
2019-03-31_16:42:48 AD.02 Channel1: -72.266
2019-03-31_16:43:20 AD.02 Channel1: -70.312
2019-03-31_16:43:21 AD.02 Channel4: -70.312
2019-03-31_16:43:53 AD.02 Channel4: -72.266
2019-03-31_16:45:27 AD.02 Channel1: -72.266
2019-03-31_16:45:58 AD.02 Channel1: -70.312
2019-03-31_16:46:31 AD.02 Channel4: -70.312
2019-03-31_16:47:03 AD.02 Channel4: -72.266
2019-03-31_16:49:09 AD.02 Channel4: -70.312
2019-03-31_16:49:40 AD.02 Channel1: -72.266
2019-03-31_16:49:41 AD.02 Channel4: -72.266
2019-03-31_16:50:11 AD.02 Channel1: -70.312
2019-03-31_16:51:47 AD.02 Channel4: -70.312
2019-03-31_16:52:19 AD.02 Channel4: -72.266
2019-03-31_16:57:35 AD.02 Channel4: -70.312
2019-03-31_16:58:07 AD.02 Channel4: -72.266
2019-03-31_16:58:38 AD.02 Channel1: -72.266
2019-03-31_16:59:09 AD.02 Channel1: -70.312
2019-03-31_17:00:14 AD.02 Channel4: -70.312
2019-03-31_17:00:45 AD.02 Channel4: -72.266
2019-03-31_17:01:17 AD.02 Channel4: -70.312
2019-03-31_17:01:49 AD.02 Channel4: -72.266
2019-03-31_17:04:58 AD.02 Channel4: -70.312
2019-03-31_17:05:30 AD.02 Channel4: -72.266
2019-03-31_17:07:04 AD.02 Channel1: -72.266
2019-03-31_17:08:07 AD.02 Channel1: -70.312
2019-03-31_17:08:39 AD.02 Channel1: -72.266
2019-03-31_17:09:10 AD.02 Channel1: -70.312
2019-03-31_17:10:14 AD.02 Channel1: -72.266
2019-03-31_17:10:45 AD.02 Channel1: -70.312
2019-03-31_17:11:18 AD.02 Channel4: -70.312
2019-03-31_17:11:50 AD.02 Channel4: -72.266
2019-03-31_17:12:20 AD.02 Channel1: -72.266
2019-03-31_17:12:52 AD.02 Channel1: -70.312
2019-03-31_17:16:33 AD.02 Channel1: -72.266
2019-03-31_17:17:05 AD.02 Channel1: -70.312
2019-03-31_17:17:37 AD.02 Channel1: -72.266
2019-03-31_17:18:08 AD.02 Channel1: -70.312
2019-03-31_17:20:47 AD.02 Channel1: -72.266
2019-03-31_17:21:18 AD.02 Channel1: -70.312
2019-03-31_17:22:21 AD.02 Channel1: -72.266
2019-03-31_17:23:25 AD.02 Channel1: -70.312
2019-03-31_17:23:56 AD.02 Channel1: -72.266
2019-03-31_17:24:28 AD.02 Channel1: -70.312
2019-03-31_17:25:31 AD.02 Channel1: -72.266
2019-03-31_17:26:03 AD.02 Channel1: -70.312
2019-03-31_17:27:07 AD.02 Channel4: -70.312
2019-03-31_17:27:38 AD.02 Channel1: -72.266
2019-03-31_17:27:39 AD.02 Channel4: -72.266
2019-03-31_17:28:41 AD.02 Channel1: -70.312
2019-03-31_17:29:44 AD.02 Channel1: -72.266
2019-03-31_17:29:46 AD.02 Channel4: -70.312
2019-03-31_17:30:17 AD.02 Channel4: -72.266
2019-03-31_17:30:48 AD.02 Channel1: -70.312
2019-03-31_17:31:52 AD.02 Channel4: -70.312
2019-03-31_17:32:24 AD.02 Channel4: -72.266
2019-03-31_17:39:14 AD.02 Channel1: -72.266
2019-03-31_17:40:17 AD.02 Channel1: -70.312
2019-03-31_17:41:52 AD.02 Channel1: -72.266
2019-03-31_17:42:25 AD.02 Channel4: -70.312
2019-03-31_17:42:55 AD.02 Channel1: -70.312
2019-03-31_17:42:57 AD.02 Channel4: -72.266
2019-03-31_17:44:30 AD.02 Channel1: -72.266
2019-03-31_17:45:02 AD.02 Channel1: -70.312
2019-03-31_17:46:05 AD.02 Channel1: -72.266
2019-03-31_17:46:37 AD.02 Channel1: -70.312
2019-03-31_17:49:15 AD.02 Channel1: -72.266
2019-03-31_17:50:18 AD.02 Channel1: -70.312
2019-03-31_17:51:23 AD.02 Channel4: -70.312
2019-03-31_17:52:26 AD.02 Channel4: -72.266
2019-03-31_17:52:56 AD.02 Channel1: -72.266
2019-03-31_17:53:28 AD.02 Channel1: -70.312
2019-03-31_17:59:48 AD.02 Channel1: -72.266
2019-03-31_18:00:51 AD.02 Channel1: -70.312
2019-03-31_18:01:54 AD.02 Channel1: -72.266
2019-03-31_18:01:55 AD.02 Channel4: -70.312
2019-03-31_18:02:26 AD.02 Channel1: -70.312
2019-03-31_18:02:27 AD.02 Channel4: -72.266
2019-03-31_18:03:29 AD.02 Channel1: -72.266
2019-03-31_18:04:01 AD.02 Channel1: -70.312
2019-03-31_18:05:04 AD.02 Channel1: -72.266
2019-03-31_18:05:36 AD.02 Channel1: -70.312
2019-03-31_18:06:39 AD.02 Channel1: -72.266
2019-03-31_18:06:40 AD.02 Channel4: -70.312
2019-03-31_18:07:12 AD.02 Channel4: -72.266
2019-03-31_18:07:42 AD.02 Channel1: -70.312
2019-03-31_18:11:56 AD.02 Channel3: -78.125
2019-03-31_18:12:28 AD.02 Channel3: -76.172
2019-03-31_18:12:58 AD.02 Channel1: -72.266
2019-03-31_18:14:02 AD.02 Channel1: -70.312
2019-03-31_18:14:33 AD.02 Channel1: -72.266
2019-03-31_18:15:05 AD.02 Channel1: -70.312
2019-03-31_18:16:40 AD.02 Channel1: -72.266
2019-03-31_18:17:43 AD.02 Channel1: -70.312
2019-03-31_18:17:43 AD.02 Channel2: -68.359
2019-03-31_18:18:15 AD.02 Channel2: -70.312
2019-03-31_18:18:46 AD.02 Channel1: -72.266
2019-03-31_18:18:48 AD.02 Channel4: -70.312
2019-03-31_18:19:18 AD.02 Channel1: -70.312
2019-03-31_18:19:19 AD.02 Channel4: -72.266
2019-03-31_18:21:56 AD.02 Channel1: -72.266
2019-03-31_18:22:28 AD.02 Channel1: -70.312
2019-03-31_18:24:34 AD.02 Channel1: -72.266
2019-03-31_18:25:06 AD.02 Channel1: -70.312
2019-03-31_18:27:44 AD.02 Channel1: -72.266
2019-03-31_18:28:47 AD.02 Channel1: -70.312
2019-03-31_18:34:36 AD.02 Channel4: -70.312
2019-03-31_18:35:08 AD.02 Channel4: -72.266
2019-03-31_18:35:40 AD.02 Channel4: -70.312
2019-03-31_18:36:11 AD.02 Channel4: -72.266
2019-03-31_18:37:15 AD.02 Channel4: -70.312
2019-03-31_18:37:46 AD.02 Channel4: -72.266
2019-03-31_18:38:48 AD.02 Channel1: -72.266
2019-03-31_18:39:20 AD.02 Channel1: -70.312
2019-03-31_18:40:55 AD.02 Channel1: -72.266
2019-03-31_18:43:33 AD.02 Channel1: -70.312
2019-03-31_18:44:05 AD.02 Channel1: -72.266
2019-03-31_18:44:36 AD.02 Channel1: -70.312
2019-03-31_18:45:08 AD.02 Channel1: -72.266
2019-03-31_18:45:40 AD.02 Channel1: -70.312
2019-03-31_18:46:11 AD.02 Channel1: -72.266
2019-03-31_18:46:43 AD.02 Channel1: -70.312
2019-03-31_18:47:46 AD.02 Channel1: -72.266
2019-03-31_18:47:47 AD.02 Channel4: -70.312
2019-03-31_18:48:18 AD.02 Channel1: -70.312
2019-03-31_18:48:19 AD.02 Channel4: -72.266
2019-03-31_18:48:51 AD.02 Channel4: -70.312
2019-03-31_18:49:22 AD.02 Channel4: -72.266
2019-03-31_18:49:53 AD.02 Channel1: -72.266
2019-03-31_18:49:54 AD.02 Channel4: -70.312
2019-03-31_18:50:24 AD.02 Channel1: -70.312
2019-03-31_18:50:25 AD.02 Channel4: -72.266
2019-03-31_18:50:56 AD.02 Channel1: -72.266
2019-03-31_18:50:56 AD.02 Channel2: -68.359
2019-03-31_18:51:27 AD.02 Channel1: -70.312
2019-03-31_18:51:28 AD.02 Channel2: -70.312
2019-03-31_18:52:32 AD.02 Channel4: -70.312
2019-03-31_18:53:04 AD.02 Channel4: -72.266
2019-03-31_18:55:42 AD.02 Channel4: -70.312
2019-03-31_18:56:13 AD.02 Channel4: -72.266
2019-03-31_18:56:44 AD.02 Channel1: -72.266
2019-03-31_18:57:15 AD.02 Channel1: -70.312
2019-03-31_19:00:25 AD.02 Channel1: -72.266
2019-03-31_19:00:26 AD.02 Channel4: -70.312
2019-03-31_19:00:58 AD.02 Channel4: -72.266
2019-03-31_19:02:00 AD.02 Channel1: -70.312
2019-03-31_19:02:32 AD.02 Channel1: -72.266
2019-03-31_19:02:33 AD.02 Channel4: -70.312
2019-03-31_19:03:03 AD.02 Channel1: -70.312
2019-03-31_19:03:05 AD.02 Channel4: -72.266
2019-03-31_19:04:08 AD.02 Channel4: -70.312
2019-03-31_19:04:40 AD.02 Channel4: -72.266
2019-03-31_19:09:23 AD.02 Channel1: -72.266
2019-03-31_19:09:55 AD.02 Channel1: -70.312
2019-03-31_19:12:34 AD.02 Channel4: -70.312
2019-03-31_19:13:36 AD.02 Channel1: -72.266
2019-03-31_19:13:37 AD.02 Channel4: -72.266
2019-03-31_19:14:08 AD.02 Channel1: -70.312
2019-03-31_19:18:21 AD.02 Channel2: -68.359
2019-03-31_19:18:53 AD.02 Channel2: -70.312
2019-03-31_19:19:25 AD.02 Channel4: -70.312
2019-03-31_19:20:29 AD.02 Channel4: -72.266
2019-03-31_19:24:09 AD.02 Channel1: -72.266
2019-03-31_19:24:40 AD.02 Channel1: -70.312
2019-03-31_19:29:26 AD.02 Channel4: -70.312
2019-03-31_19:29:58 AD.02 Channel4: -72.266
2019-03-31_19:33:38 AD.02 Channel1: -72.266
2019-03-31_19:34:10 AD.02 Channel1: -70.312
2019-03-31_19:35:45 AD.02 Channel1: -72.266
2019-03-31_19:36:18 AD.02 Channel4: -70.312
2019-03-31_19:36:48 AD.02 Channel1: -70.312
2019-03-31_19:36:49 AD.02 Channel4: -72.266
2019-03-31_19:40:29 AD.02 Channel1: -72.266
2019-03-31_19:42:04 AD.02 Channel1: -70.312
2019-03-31_19:43:08 AD.02 Channel1: -72.266
2019-03-31_19:43:39 AD.02 Channel1: -70.312

Wzut

#7
01 April 2019, 07:40:45 Letzte Bearbeitung: 01 April 2019, 07:46:05 von Wzut
Zitat von: M_I_B am 31 März 2019, 20:00:14
... warum sollten die unbeding gleich sein?
Keine Ahnung, du addierst doch in deinem userReading für beide Kanäle den gleichen Offset.
So langsam versteh ich weder dein Problem noch den Sinn dahinter nicht mehr, deine Werte zappeln um einen wert X und du addierst fixe Offsets dazu und erwartest dann das immer 0 dabei herauskommt ?

Edit oder stört dich nur das dort -1.95400000000001 steht statt -1.954 ?? also lediglich die 00000000001 sollen weg ?
Wenn das alles ist so ist sprintf mit "%.3f" dein Freund für die user Readings, allerdinsg wird dann auch die simple 0 zur 0.000. Die wird aber mit einem zusätzlichen +=0 wieder zur nackten 0
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

M_I_B

#8
01 April 2019, 07:53:09 Letzte Bearbeitung: 01 April 2019, 07:57:08 von M_I_B
... ja, wir reden offensichtlich aneinander vorbei, also der Reihe nach:

1. RAW- Werte:
Damit ist im späteren Umfeld doof zu rechnen und erst recht schlecht zu erkennen, wenn was nicht so ist wie es soll

2. Offset- korrigierte Werte:
Haben den Sinn, ohne Einganssignal einen Wert umzu "0" zu generieren (siehe 1.).  Der bereits in den RAW- Werten enthaltene Jitter (entsprechend +/-1bit aus dem A/D) wird im späteren Verlauf eliminiert

3. Das Problem:
Die in den UserReadings korrigierten Werte (siehe 2.) sollten entweder "0" sein oder aber um den Betrag des Jitters von "0" abweichen. Da hier in beiden Fällen (RAW und Offset-Korrektur) mit drei Dezimalstellen gerechnet wird und ausschließlich mit einer Addition, kann als Ergebnis auch nur ein Wert mit drei Dezimalstellen heraus kommen.

*** Tut es aber nicht! ***

Es tauchen hier Werte auf mit 14 Dezimalstellen, was mathematisch unmöglich ist. Und genau das ist mein Problem

Wo kommen diese Werte resp. mathematischen Unmöglichkeiten bei einer schnöden Addition her ????

ZitatEdit oder stört dich nur das dort -1.95400000000001 steht statt -1.954 ?? also lediglich die 00000000001 sollen weg ?
Ja, genau das soll weg, aber mir geht es hier mehr darum, die Ursache dieser Unmöglichkeit zu eliminieren und nicht um Symtombekämpfung per sprintf

Wzut

#9
01 April 2019, 08:05:18
Die Ursache ist Perl selbst und wie math Operationen intern durchgeführt werden.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

M_I_B

#10
01 April 2019, 08:10:52
... ufff! ... Ernsthaft jetzt?
Wie an anderer Stelle bemerkt bin ich kein Coder und habe von PERL selbst keine Ahnung. Aber ich bin eigentlich davon ausgegangen, das Sprachen wie PERL & Co. solcherlei Probleme bei simplen Additionen gar nicht kennen ... Das finde ich jetzt echt schräg :o

Aber immerhin sprechen wir jetzt vom selben Problem ;D

Kann man PERL irgendwie korrektes Verhalten beibiegen, so das hier spätere Symtombekämpfungen vermeidbar sind?

Wzut

#11
01 April 2019, 10:06:05
Nunja , simple Addition wäre 72 -71 du benutzt aber keine simplen Integer Zahlen sondern Fließkomma,
und hier muß man einfach im Hinterkopf haben wie eine Fließkomma Zahl intern Binär abgelegt und behandelt wird. Das ist kein wirkliches Perl Problem sondern betrifft auch andere Sprachen.
Hier mal ein simples Beispiel zum Testen :
Code Auswählen
#!/bin/perl

$a = -72.266;
$b = 70.312;
$c = $a+$b;

print $c."\n";
$c= sprintf("%.3f",$c);
print $c."\n\n";


$b = $a;
$c = $a-$b;
$c= sprintf("%.3f",$c);
print $c."\n";
$c+=0;
print $c."\n";
ergibt als Ausgabe :
Code Auswählen
-1.95400000000001
-1.954

0
0.000
0



Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

M_I_B

#12
01 April 2019, 22:44:09
... japp, habe ich mal gemacht... Tatsächlich; is ja doof  :o

Nun gut... Lässt sich an der Basis nicht ändern; habe alles auf sprintf umgestellt ...


Vielen Dank für die Erklärung! Muss ich mir unbedingt merken für's nächste mal ...
Drucken
Nach oben Seiten1
Benutzer-Aktionen