Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 5 von 5 ErsteErste ... 345
Ergebnis 41 bis 44 von 44

Thema: Rundungsfehler

  1. #41
    Registriert seit
    06.10.2003
    Beiträge
    3.409
    Danke
    449
    Erhielt 504 Danke für 407 Beiträge

    Standard


    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.



    Zitat Zitat von borromeus Beitrag anzeigen
    .. 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:
    Code:
          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.
    Geändert von Onkel Dagobert (03.12.2015 um 22:31 Uhr)
    Es gibt viel mehr Leute, die freiwillig aufgeben, als solche, die echt scheitern.
    Henry Ford

  2. #42
    borromeus ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    08.02.2007
    Ort
    A-2320
    Beiträge
    2.252
    Danke
    244
    Erhielt 332 Danke für 303 Beiträge

    Standard

    Zitat Zitat von ebt'ler Beitrag anzeigen
    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, Rundungsfehler
    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.

  3. #43
    borromeus ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    08.02.2007
    Ort
    A-2320
    Beiträge
    2.252
    Danke
    244
    Erhielt 332 Danke für 303 Beiträge

    Standard

    @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.

  4. #44
    Registriert seit
    04.11.2015
    Beiträge
    17
    Danke
    4
    Erhielt 3 Danke für 3 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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.

Ähnliche Themen

  1. Rundungsfehler
    Von Bensen83 im Forum CODESYS und IEC61131
    Antworten: 4
    Letzter Beitrag: 14.10.2012, 17:17
  2. Rundungsfehler in SCL
    Von Bensen83 im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 12.01.2011, 16:25
  3. Rundungsfehler bei Realzahlen
    Von GFI im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 25.01.2008, 16:56

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •