Kennt jemand einen schnellen, effizienten Algortihmus zur Berechnung des Betrags einer komplexen Zahl?
Gast
#6009025
Christoph M. schrieb: > Kennt jemand einen schnellen, effizienten Algortihmus zur > Berechnung des > Betrags einer komplexen Zahl? klar: float mag = sqrt (re*re+im*im); Wenn Du es schneller brauchst, dann sag uns für welche Platform Du es brauchst und was für eine Genauigkeit Dir vorschwebt.
>Wenn Du es schneller brauchst, Danke für die Antwort. Ich will die Amplitude von int16_t. Hier gibt's eine ziemlich schnelle Methode: https://dspguru.com/dsp/tricks/magnitude-estimator/ Allerdings ist mir unklar, ob die in der Tabelle tatsächlich 25dB Fehler meinen.
Gast
#6009197
Das schnellste ist https://en.m.wikipedia.org/wiki/Alpha_max_plus_beta_min_algorithm Kann man auch noch bisschen auf Genauigkeit tunen, in dem man je nach Bereich unterschiedliche Koeffizienten verwendet. Alternativ wäre CORDIC auch eine Möglichkeit
>Das schnellste ist
Danke, das ist der aus dem Link weiter vorne, aber mit besserer
Beschreibung und noch einer Approximation mehr. Mal sehen, ca. 1.2%
Fehler ist gar nicht so schlecht für 3 Multiplikationen und ein wenige
Hühnerfutter.
Cordic ist mir glaube ich zu rechenintensiv.
Angehängte Dateien:
-
CPLX_ABS_Estimation.png
(20 KB)
Christoph M. schrieb: > CPLX_ABS_Estimation.png Dieses Verfahren lässt sich verallgemeinern:
Für optimale Parameter α_i und β_i beträgt der maximale relative Fehler
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
Dafür werden jeweils 2n Multiplikationen benötigt. Mit α₀=1 und evtl. auch β₀ und entsprechender Anpassung der anderen Parameter spart man eine oder zwei Multiplikation ein, ohne dass die Genauigkeit des Ergebnisses allzu sehr darunter leidet. Nur ist dann die Berechnung der Parameter nicht mehr ganz so einfach. Spätestens für n=8 lohnt sich das Verfahren nicht mehr, da man mit 17 Multiplikationen den Betrag auch klassisch (Wurzel aus der Summe der Quadrate) wesentlich genauer berechnen kann.
Gast
#6057767
El Ef schrieb: > Alternativ wäre CORDIC auch eine Möglichkeit Cordic ist so ziemlich das Langsamste in der Reihe der genannten Methoden. Ich bin eher für die Tabellenlösung, die man noch optimieren kann, wenn man die beiden Werte so tauscht, dass jeweils immer der größere berechnet wird.