Step 7 Rundungsfehler

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Liebe Leute, bevor ihr morgen weiter macht, empfehle ich euch folgende Lektüre:

Wie genau kann ich mit REAL Zahlen rechnen, die in umfangreichen Formeln verwendet werden?

Entscheident ist folgende Aussage:

.. Beim Addieren und Subtrahieren werden die Exponenten angeglichen. D. h. die Basis und die Exponenten sind beim Addieren und Subtrahieren gleich, es werden nur die Mantissen addiert...

Die Exponenten werden angeglichen! Das bedeutet dass bei großen Unterschieden der Exponenten, Stellen der Mantisse einfach abgeschnitten werden. Das geht soweit, bis gar keine Stellen übrgig bleiben und somit keine Addition mehr stattfindet, bzw. nur noch eine Addition mit 0.0.

@ducati, was das für deinen Code bedeutet, kannst du dir selbst ableiten. Wenn man weniger viele Werte addiert, geht's mit Real noch gut. Ich habe es in meinen Bausteinen auch schon so gemacht. Richtig bzw. empfehlenswert ist es aber nicht.

@borromeus, du bist auf dem richtigen Weg. Ich weiß nicht was nach ducatis Aussage an der Rundung oder Berechnung nach falsch sein sollte. Bei der Addition ganzzahlige Werte gibt es keine Rundungsfehler. Ob die Genauigkeit dieser Werte nun bei einem oder bei zehn Prozent liegt, ist dabei scheiß egal.

.. Deinen Gedanken mit: "den aktuellen Mittelwert anstatt des ältesten Wertes von der Summe zu subtrahieren." verstehe ich leider nicht...

Was gibt es daran nicht zu verstehen? Kürzer und präziser kann man es doch garnicht beschreiben. In ducatis Code steckt das selbe Prinzip, nur halt mit Realzahlen.

Vielleicht wird es in deinen Code eingebaut deutlicher:

      L     #Summe_DI
      L     #Mittelwert                 // alter Mittelwert
      -D    
      T     #Summe_DI                   // alten Mittelwert von Summe abziehen

      L     #PV_IN
      L     1.000000e+002
      *R    
      RND   
//    T     D [AR1,P#0.0]               // neuer Wert
      L     #Summe_DI
      +D    
      T     #Summe_DI                   // neuen Wert zur Summe dazuaddieren

Das Ergebnis ist allerdings nicht der arithmetische Mittelwert. Die Gewichtung liegt auf dem aktuellen Messwert.

 

[borromeus]

Dann füge doch noch eine dritte Variante hinzu. Und zwar Schleife mittels DINT. Wenn der ursprüngliche Realwert nicht mehr als zwei Kommastellen besitzt und du diesen mit 100 multiplizierst, dann begehst du keinen Rundungsfehler.
In diesen Fall sollte die Berechnung unabhänig vom Rechweg sein. Ob nun via Schleife oder via Addition / Subtaktion, beides sollte das gleiche Ergebniss liefern.

Wie man bei deiner PDF auf Seite 3 und 6 sieht, ist bei Real-Werten der Genauigkeitsbereich bereits ausgeschöpft. 1903784,0 und 1895165.0 haben bereits 7 Vorkommastellen. Ab dem Zeitpunkt in dem die Stellen ausgenutzt sind wird beim Addieren (in der Schleife) der Nachkommaanteil nicht mehr richtig Berücksichtigt. Daher Läuft der Wert weg. (EDIT: zu kleineren Werten hin)
Das siehst du auch daran, dass der Real-Summenwert kleiner als der Vergleichswert wird.

Bei DINT hast du hingegen alle Stellen berücksichtigt. Du musst nur aufpassen den maximalen Wertebreich nicht zu Überschreiten, falls der Mittelwert mal über einen längeren Zeitrahmen gebildet werden soll.

Korrigier mich, wenn ich jetzt falsch liege. Aber so denk ich mir das erstmal, nach den vorliegenden Informationen.

Danke für den Beitrag.
Wenn ich 2160 Werte addiere und es mittle, ist es mir egal ob es um 1% falsch ist- egal ob REAL oder DINT.
Es geht ja hier nur mehr darum, ob die Werte "davonlaufen" wenn man den 2160ten Wert (älteste) von der Summe abzieht und den neuesten wieder addiert. Sie laufen nicht davon. Ich hatte da leider einen Fehler weil die Schleife einen Wert zu lang war, das wirkt sich bei der Variante mit den REAL-Zahlen- also wo ich alles zusammenzähle und dividiere nicht aus, bei den DINT's schon weil ich pro Umlauf des Puffers 1x zuviel addiere.

Der Beitrag warum ich das überhaupt so programmiert habe ist ja der von Aventinus, http://www.sps-forum.de/simatic/80056-rundungsfehler-2.html#post604125
Dann habe ich also die fertige funktionierene Lösung mit der Addierschleife gekübelt und eine zweite programmiert und siehe da.... sie ist, wie befürchtet überraschenderweise doch weggedriftet.... nur halt wegen eines Programmierfehlers.

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Onkel und @Ducati

wahrscheinlich ist es philosophisch zu diskutieren was ein 6h Mittelwert ist.
Für mich ist das (in diesem Fall) die Summe der letzten 2160 Werte (alle 10s einer) durch 2160.
Da gibt es keine Gewichtung.

Die technische Anwendung bilanziert Zu- und Abfluss in ein Werk. Die Flüsse sollen im Mittel gleichgehalten werden.

 

[EXOR]

Schön, dass es geklappt hat

Ansonsten kann ich nur Empfehlen, einmal den allgemeinen Aufbau von REAL-Zahlen (IEEE - 754) zu studieren. Es braucht zwar etwas Zeit, doch wenn man diesen einmal begriffen und selber von Hand berechnet hat, ist die Chance auf die Nase zu fallen doch um einiges kleiner.