TIA Zahlensysteme - Zähler weicht ab in REAL

[Drumfan159]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi zusammen,

hätte mal eine allgemeine Frage zu den Zahlensystemen bzw. speziell REAL....
Lustiges Phänomen beim Kunden: Nach jahrerlanger Arbeit meinte er plötzlich "Sein Zählwert (Durchflussmenge)" stimmt nicht mehr. Und zwar wird bei einem Taktsignal eines Durchflusszählers immer um 1,5L gezählt. Nun ist der Zähler bei einem Bestimmte Wert angekommen: 8.388.608,0 - - -> entsprich 2²³.
Ab diesem Wert erfasst der Datentyp REAL die Kommastelle bei 1,5 nicht mehr sondern runded beim Zählwert addieren gleich auf 2,0 auf.

Meine Frage nun, wieso ist das so? Warum erkennt er bei 2 hoch 23 die Kommastelle nicht mehr richtig?

Ich habe schon eine Lösung gefunden, und zwar rechne ich das Ganze gleich von Liter auf m³ um, sollte dann doch eine gaaaaanze weile wieder laufen^^.


Vielleicht kann mir der ein oder andere meine Verständnisfrage beantworten.

Gruß Drumfan.

 

[Larry Laffer]

Dazu musst du dir einfach mal die Darstellung der REAL-Zahl ansehen ...
Ich gehe da jetzt mal nicht auf den internen Aufbau der Zahl ein - das kannst du aber auch nach-googeln : https://www.sps-lehrgang.de/zahlenformate-step7/
Du hast eine Vorkommastelle und 6 Nachkommastellen und dann hast du den Exponenten. Das heißt deine Genauigkeit bewegt sich, das sich deine Nachkommastellenzahl ja nicht ändern kann, im Bereich deines Exponenten. Je größer der wird umso ungenauer wird deine REAL-Zahl.
Es macht hier also schon Sinn, zu schauen was man wie braucht ...

Gruß
Larry

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Lustiges Phänomen beim Kunden: (...)
Ich habe schon eine Lösung gefunden, und zwar rechne ich das Ganze gleich von Liter auf m³ um, sollte dann doch eine gaaaaanze weile wieder laufen^^.

Ob Du nun z.B. "1234567.8 l + 1.5 l" rechnest oder "1234.5678 m³ + 0.0015 m³" macht keinen Unterschied. Dein Zähler muß weniger Dezimalziffern (Ziffernstellen) beanspruchen, oder Zahlenformate mit mehr möglichen Ziffernstellen benutzen, oder mehrere Zähler kaskadieren.

Dieses Verhalten ist eigentlich kein lustiges Phänomen, sondern ist schon seit dem Design des Formats des Datentyps für Gleitkommazahlen (Float, REAL) nach IEEE 754 seit knapp 40 Jahren bekannt - nur zu viele Programmierer wissen das leider nicht bzw. haben sich darüber zu wenig Gedanken gemacht. :sad: Und so kommt das Thema immer wieder hoch Zuletzt vor zwei Wochen hier: Zähler, der mit Real-Zahl arbeitet Im Beitrag #13 findest Du da einen Vergleich, wie weit man mit welchem (heutigen) Standard-Datentyp ohne Genauigkeitsverlust in der Praxis zählen kann. "Zählen" mit Gleitkommazahlen ist die schlechtest-mögliche Entscheidung.

Harald

 

[DeltaMikeAir]

Dieses Verhalten ist eigentlich kein lustiges Phänomen...

Ja, stimmt. Wenn man sich man mal mit dem Thema genauer befasst hat, dann reicht die Überschrift "Zahlensysteme - Zähler weicht ab in REAL"
schon um zu wissen was los ist.

 

[Olli_BS]

Oder anders gesagt: In 4 Bytes lässt sich nicht die Unendlichkeit abbilden ...

Wenn Du eine 1500er hast, kannst du aber auf LREAL umstellen. Das sind 8 Bytes. Dann hast du wieder "jahrelang" Ruhe.

 

[Windoze]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da du nur ein Taktsignal Zählen musst, kannst du auch einen DInt benutzen und die Impulse Zählen.
Zur Ausgabe dann mit den 1,5L pro Impuls multiplizieren.

 

[Heinileini]

Dieses Verhalten ist eigentlich kein lustiges Phänomen, sondern ist schon seit dem Design des Formats des Datentyps für Gleitkommazahlen (Float, REAL) nach IEEE 754 seit knapp 40 Jahren bekannt ...

Seit knapp 40 Jahren, Harald? Lääänger, viel länger und nicht erst seit IEEE 754! Den heutigen Programmierern fehlt anscheinend die Erfahrung mit dem SchätzEisen genannt RechenSchieber.
(Jetzt bitte kein Vortrag über RechenSchieber - ich weiss, dass sie Logarithmen addieren/subtrahieren, um damit zu multiplizieren/dividieren u.s.w.)
Vor 40 Jahren war schon meine hp-TaschenRechnerSammelPeriode beendet (hp25, hp29, hp19 [wie hp29, aber mit Drucker], hp97 [wie hp67, aber als Tischrechner mit Drucker], hp41).

 

[PN/DP]

Heinrich, Deine hp-Geräte haben möglicherweise ein anderes herstellerspezifisches Gleitkommazahlen-Format benutzt (so wie auch die S5)? (ich weiß es nicht) Das heute allgemein verwendete Format nach IEEE 754 wurde von der IEEE erst 1985 konzipiert. Es kann natürlich sein, daß jemand schon früher "sein" Gleitkommaformat genauso codiert hat.

Harald

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da du nur ein Taktsignal Zählen musst, kannst du auch einen DInt benutzen und die Impulse Zählen.
Zur Ausgabe dann mit den 1,5L pro Impuls multiplizieren.

Dann darf sich aber im Leben des Durchflusszählers niemals die Wertigkeit des Impulses ändern. Z.B. das seit vielen Jahren verwendete Qualitäts-Zählrad ist nun doch mal kaputt/verschlissen und wird ausgetauscht gegen ein Billigimport-Modell, was nicht sooo exakt gefertigt wurde und leider schon nach 1,483 l einen Impuls ausgibt...

Harald

 

[Onkel Dagobert]

Harald, ohne die Impulswertigkeit wird es aber ganz schwierig mit dem Zählwert, besonders wenn diese sich im Leben des Zählers ändert. Aber man muss ja alle Eventualitäten in Betracht ziehen .

 

[Heinileini]

Es kann natürlich sein, daß jemand schon früher "sein" Gleitkommaformat genauso codiert hat.

Ob früher oder später, ob genauso codiert oder nur so ähnlich, das spielt doch keine Rolle, Harald.
Die Codierung als Mantisse und Exponent (und die Art der Codierung der beiden Vorzeichen) sorgt automatisch durch den grossen WerteBereich, der damit scheinbar(!) genau abgedeckt werden kann, dafür, dass Wunder erwartet werden bezüglich der Genauigkeit von Additionen/Subtraktionen von "sehr grossen" und "sehr kleiner" Zahlen. Der prozentuale Fehler ist zwar recht gering und für viele Berechnungen mehr als ausreichend, aber nicht, wenn es um "ErbsenZählerei" geht. Beim Thema "ErbsenZählerei" landet man sehr schnell, wenn z.B. BetriebsStunden gezählt werden sollen, dies aber mit einer Genauigkeit von ms oder noch lieber ns. Der Begriff "Erbsen" ist ja schon ein Bisschen irreführend - ich stelle mir lieber einen mit Sand gefüllten Eimer vor. Wen interessiert da normalerweise, wie viele Sandkörner sich im Eimer befinden?

Das einzig raffinierte an der heute gebräuchlichsten Art GleitkommaZahlen zu codieren, ist das Einsparen der höchstwertigen 1 der Mantisse. Die Genauigkeit wird so um den Faktor 2 verbessert. Das "Verschieben" des Exponenten, so dass hierfür nur positive Zahlen auftreten, bringt in diesem Sinne keine bessere Genauigkeit, sondern dient nur dazu, dass sich GleitkommaZahlen leicht vergleichen lassen.