Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
Um eine Zahl darzustellen gibt es viele Formate. Alle stehen unter folgenden "Zwängen";
möglichst wenig Speicherplatz
möglichst genaue und schnelle Rechenoperationen
möglichst großer Zahlenbereich
Diese Forderungen widersprechen einander, so dass es eben viele Formate gibt.
Zum Format Real:
Hier reicht der Zahlenbereich von ca. +/-10^(- 38) bis +/-10^(+ 38). Die Zahlen sind auf 6 Stellen nach dem Komma genau. Dafür werden je Zahl 32 Bit benötigt und es wird bei der Darstellung einigermaßen herumgetrickst (z.B. Hiddenbit, Vorzeichenbit wird weggebeamt usw.). Die Wertigkeit des wertkleinsten Bit beträgt 2^(-23)=0,0000001192.
D.h. aber: keine "absolute" Genauigkeit!
Beim Format LReal werden je Zahl 64 Bit verwendet. Die Folge ist ein Zahlenbereich von ca. +/-10^(- 128) bis +/-10^(+ 128), bei einer Genauigkeit von 15 Stellen nach dem Komma, also auch nicht absolut genau.
Normalerweise braucht sich der Anwender um solche Fragen nicht zu kümmern. Er sollte nur das "richtige" Format verwenden. Deshalb halte ich es auch für völlig unsinnig, z.B. die Zahl Pi mit zig Stellen nach dem Komma in einem Programm zu verwenden (oscat.lib). Spezielle Anwendungen, wie z.B. das Markscheidewesen im Bergbau benötigen hochgenaue Formate, weil die exakte Position in der Regel über Dreiecksberechnungen erfolgt und bei einem sinuswert mit 6 Stellen nach dem Komma z.B. ein Autotunnel irgendwo, aber nicht am geplanten Ort wieder das Tageslicht erreichen würde.
Gruß Norbert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-12-22
Originally created by: Bernhard Werner
Hallo,
um das mal klarzustellen: in CoDeSys werden REALs nie "per Hand" verarbeitet. Entweder bietet der Prozessor bereits spezielle Befehle für Real-Operationen, oder es werden Funktionen im LZS aufgerufen.
Für Genauigkeit der REAL-Verarbeitung ist entweder der Prozessor oder die math.lib im LZS verantwortlich.
Bernhard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bei arbeiten mit Real und LREAL Zahlen sind mihr Ungenauigkeiten aufgefallen.
Wenn man z.B. 134,11 - 126,91 Rechnet bekommen ich als Ergebnis 7.20000000000002. ( als LRela berechnet ! )
Kann jemand das erklären ?
mein Beispiel Prgogramm
VAR
END_VAR
lrTest := X1 - X2 ;
mfG Jochen Schohaus
Hi J Schohaus
Das haben sehr viele "Von Neumann" - Rechner, und Programierumgebungen .
Bei Finanz-Daten ... wo dieses NICHT sein darf, gibt es dafür speziele
"Geld"-Zahlenformate.
Hallo
hier mal eine Kurzübersicht über Zahlenformate:
Um eine Zahl darzustellen gibt es viele Formate. Alle stehen unter folgenden "Zwängen";
möglichst wenig Speicherplatz
möglichst genaue und schnelle Rechenoperationen
möglichst großer Zahlenbereich
Diese Forderungen widersprechen einander, so dass es eben viele Formate gibt.
Zum Format Real:
Hier reicht der Zahlenbereich von ca. +/-10^(- 38) bis +/-10^(+ 38). Die Zahlen sind auf 6 Stellen nach dem Komma genau. Dafür werden je Zahl 32 Bit benötigt und es wird bei der Darstellung einigermaßen herumgetrickst (z.B. Hiddenbit, Vorzeichenbit wird weggebeamt usw.). Die Wertigkeit des wertkleinsten Bit beträgt 2^(-23)=0,0000001192.
D.h. aber: keine "absolute" Genauigkeit!
Beim Format LReal werden je Zahl 64 Bit verwendet. Die Folge ist ein Zahlenbereich von ca. +/-10^(- 128) bis +/-10^(+ 128), bei einer Genauigkeit von 15 Stellen nach dem Komma, also auch nicht absolut genau.
Normalerweise braucht sich der Anwender um solche Fragen nicht zu kümmern. Er sollte nur das "richtige" Format verwenden. Deshalb halte ich es auch für völlig unsinnig, z.B. die Zahl Pi mit zig Stellen nach dem Komma in einem Programm zu verwenden (oscat.lib). Spezielle Anwendungen, wie z.B. das Markscheidewesen im Bergbau benötigen hochgenaue Formate, weil die exakte Position in der Regel über Dreiecksberechnungen erfolgt und bei einem sinuswert mit 6 Stellen nach dem Komma z.B. ein Autotunnel irgendwo, aber nicht am geplanten Ort wieder das Tageslicht erreichen würde.
Gruß Norbert
Originally created by: Bernhard Werner
Hallo,
um das mal klarzustellen: in CoDeSys werden REALs nie "per Hand" verarbeitet. Entweder bietet der Prozessor bereits spezielle Befehle für Real-Operationen, oder es werden Funktionen im LZS aufgerufen.
Für Genauigkeit der REAL-Verarbeitung ist entweder der Prozessor oder die math.lib im LZS verantwortlich.
Bernhard