Betrag (cplx) schnell berechnen

[Christoph M. (mchris)]

Kennt jemand einen schnellen, effizienten Algortihmus zur Berechnung des 
Betrags einer komplexen Zahl?

[Nils (Gast)]

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.

[Christoph M. (mchris)]

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

[El Ef (Gast)]

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

[Christoph M. (mchris)]

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

[Yalu X. (yalu) (Moderator)]

Christoph M. schrieb:
> CPLX_ABS_Estimation.png

Dieses Verfahren lässt sich verallgemeinern:

$$|z|\approx\max_{i=0}^{n-1}(\alpha_i\mathrm{Max}+\beta_i\mathrm{Min})$$

Für optimale Parameter α_i und β_i beträgt der maximale relative Fehler

$$\frac 2{1+\cos\frac\pi{8n}}-1$$

     max. rel.
 n    Fehler
——————————————
 1    3.957%
 2    0.970%
 3    0.430%
 4    0.241%
 5    0.154%
 6    0.107%
 7    0.079%
 8    0.060%
——————————————

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.

[Michael W. (Gast)]

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.