Hat jemand zufällig den HDL-Coder schon mal dazu gebraucht, statistisch zu runden? Gibt es dafür eine box oder muss man das selber machen?
Was ist denn statistisches Runden? Wikipedia kennt es nicht: https://de.wikipedia.org/wiki/Rundung
Und falls es der HDL-Coder kann, sollte es in dessen Doku stehen, oder?
Es geht wohl um Runden bei "*.5" .
In HDL schneidet man gern lsb ohne Berücktsichtigung der msb ab, (Auf-)Runden nach der Geradzahlregel (so hiess es wohl an "meiner" Grundschule) wird in FPGA-Logik schnell aufwendig (Adder/Incrementer für den Rest).
Wird wohl auch unter "round or truncate" diskutiert.
:
Bearbeitet durch User
Was ist denn statistisches Runden?
Mittels statistischer Funktionen auf und abrunden, damit sich über die Zeit sinnvolle Mittelwerte ergeben und nicht Werte, die längere Zeit bei >0,5 und <1,0 liegen ständig eine anhaltende 1 erzeugen.
Wikipedia kennt es nicht:
Wikipedia kennt vieles nicht. Ich habe das von meinem Mathelehrer aus den 1980ern. Wird (wurde ?) wohl für die damals gebrächlichen niedrigen Auflösungen von CPUs genutzt.
Und falls es der HDL-Coder kann
Ich habe nichts gefunden - vermute(te) aber daß man es in einer toolbox finden könnte.
Was noch erwähnenswert ist: Es geht um INTEGER-Berechnung. Bei heutigen Anwendungen tritt das Problem kaum auf, das REAL benutzt.
Es geht wohl um Runden bei "*.5" .
Nicht nur, allerdings ist es da mit am Wichtigsten.
In HDL schneidet man gern lsb ohne Berücktsichtigung der msb ab,
Ja, das machen die Meisten und schleppen sich damit entsprechende Fehler ein.
(Auf-)Runden ... wird in FPGA-Logik schnell aufwendig
Man braucht einen Addierer vor dem Abschneiden - oder aber man rundet eben statistisch VOR oder sogar NACH der Berechnung.
Hier ist das Problem am Beispiel eines Sinussignals: Rundet man durch klassisches Aufrunden, entsteht ein u.U. langes Rechteck. Durch ein (hier einfaches alternierendes) Runden bekommt man eine Funktion, welche das reale Signal im Mittel besser repräsentiert.
Angehängte Dateien:
-
runden.jpg
(84 KB)
Hier ist eine Tabelle für eine INT-Multiplikation mit Werten die (als Beispiel) auf 2 Bit genau sind. Danaben das Ergebnis in Real. In den Zeilen darunter einmal Abschneiden, Runden und statistisches Runden mit jeweils der sich ergebenden Differenz. Bei normalen Runden ergeben sich immer Muster, beim Abschneiden ist der Wert zudem zu tief. Da ließe sich dann, wie oben schon erwähnt, im Nachhinein ein Wert beaufschlagen.
Angehängte Dateien:
-
Statistisches_Runden.jpg
(240 KB)
(*) vorweg: Von VHDL & Co. habe ich super wenig Ahnung, steuere bloß mal ein paar allgemeine Gedanken bei...
Hier ist das Problem am Beispiel eines Sinussignals: [...]
Ich kannte "wissenschaftliches Runden" = zusätzliche Regel, um die Asymmetrie des kaufmännischen Rundens (in 5 Fällen auf-, nur in 4 Fällen abrunden) im statistischen Mittel zu beseitigen.
Dein Beispiel mit dem Sinussignal: Kann eine bestimmte Rundungsstrategie da überhaupt helfen? Sich langsam ändernde Werte "kleben" ja (bei deterministischer Rundungsregel) so oder so eine Weile am jeweiligen korrekt gerundeten Wert fest.
Was Du als "statistisches Runden" beschreibst, hört sich für mich nach dem Einfügen von künstlichem Rauschen an (was vom Effekt her dann auf eine "mal-so-mal-so"-Rundungsregel hinausläuft).
Erinnert mich an Phänomene, die man bei Audio-/Signalverarbeitung haben kann, Stichworte "Quantisierungsfehler"/"Dithering".
Beispiel: Glaube die ersten Versionen des Audio-Editors Audacity hatten kein eingebautes Dithering. Hat man z.B. bei 16-Bit-PCM-Audio ein Fadeout gemacht, dann ergaben sich, kurz bevor eigentlich Stille eintreten sollte, schreckliche lautsprecherzerfetzende Störgeräusche - nicht als Fehler, sondern weil das aus Sicht des DA-Wandlers dann halt so in den digitalen Daten codiert und verlangt ist. Um dem zu entgehen, half es, das ausklingende Signal abschließend nochmal mit einigen dB weißem Rauschen zu überlagern.
==> vielleicht hilfreich, mal bzgl. "Dithering" weiterzuforschen, oder zu prüfen, ob sich das Problem in Deinem Anwendungsfall auch einfach durch Hinzufügen von künstlichem Rauschen austricksen ließe. (Sofern Gleitkommaarithmetik keine Option ist - vermutlich nicht(?) - ähm, wie gesagt: siehe ganz oben: (*) )
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.