nonzero phase spectrum from FFT of even function with zero imag part
in [DSP]
|
Prev: Phase-frequency detector with synchronous output?
Next: nonzero phase spectrum from FFT of even function with zero imag part
From: Dirk Bell on 26 Jun 2010 13:00 On Jun 24, 5:12 pm, "fisico32" <marcoscipioni1(a)n_o_s_p_a_m.gmail.com> wrote: > Hello Forum, > > the fft of a rectangular, even, symmetric sequence show a nonzero real part > and a zero imaginary part. All good so far. > > However the phase spectrum is nonzero: zero at some frequencies, pi at some > frequencies , -pi at some others.... > > The phase spectrum is given by atan(Imag(fft)/real(fft)), so it should give > zero.... > > why not? > > thanks > fisico32 fisico32, Your result is not surpising. If the amplitude of the spectrum is strictly real, then if the amplitude (not the magnitude) goes negative you will get a phase of +-pi (the sign depends on your software). Now consider when the ideal result should be strictly real, but there is a very small imaginary part (0 with computational error). When the real part of the of the FFT output (not the magnitude) goes negative, the sign of the computational error for the "zero" imaginary part will determine whether your software gives you a phase of essentially +pi or -pi ( when the imaginary part is >0) or essentially 0 (when the imaginary part is <0). As mentioned in a previous post, if the ideal real part is 0 and the ideal imaginary part is 0, with computational noise !=0, the result is not predictable or meaningful. Dirk
From: Dirk Bell on 26 Jun 2010 13:05 On Jun 24, 5:12 pm, "fisico32" <marcoscipioni1(a)n_o_s_p_a_m.gmail.com> wrote: > Hello Forum, > > the fft of a rectangular, even, symmetric sequence show a nonzero real part > and a zero imaginary part. All good so far. > > However the phase spectrum is nonzero: zero at some frequencies, pi at some > frequencies , -pi at some others.... > > The phase spectrum is given by atan(Imag(fft)/real(fft)), so it should give > zero.... > > why not? > > thanks > fisico32 fisico32, Your result is not surpising. If the amplitude of the spectrum is strictly real, then if the amplitude (not the magnitude) goes negative you will get a phase of +-pi (the sign depends on your software). Now consider when the ideal result should be strictly real, but there is a very small imaginary part (0 with computational error). When the real part of the of the FFT output (not the magnitude) goes negative, the sign of the computational error for the "zero" imaginary part will determine whether your software gives you a phase of essentially +pi or -pi ( when the imaginary part is >0) or essentially 0 (when the imaginary part is <0). Dirk
From: robert bristow-johnson on 26 Jun 2010 21:54 On Jun 24, 5:48 pm, "fisico32" <marcoscipioni1(a)n_o_s_p_a_m.gmail.com> wrote: > >On Jun 24, 5:12=A0pm, "fisico32" <marcoscipioni1(a)n_o_s_p_a_m.gmail.com> .... > >> why not? > r b-j said (with spelling correction) > >you didn't swap the two halves with fftshift(). > > >r b-j > > Actually, on page 101 of Understanding digital signal processing by Richard > Lyon , it is said (at the bottom) that " the particular pattern of pi and > -pi values is an artifact of the software used to generate that figure. A > different software package may show a different pattern.... as long as the > nonzero phase samples are either +pi or -pi the phase results will be > correct" > > Is this related to the fftshift you are mentioning? i dunno if Rick's thing is related until i dig the book out of the correct box (since moving it from Waltham Mass back to Vermont, all of my books are in boxes). if Rick is saying what i think you are crediting him for saying, then i think that Rick is sorta incorrect. this *is* directly related to failing to use fftshift() (or it's counterpart in whatever language or package you are using) before applying the FFT. if you have a vector of data (with indices 0 to N-1) that is extracted from some continuous stream of data much longer than N, and if you apply a window (like the Hann or Hamming or Kaiser or whatever) to that vector such that the middle of that vector (around index N/2) is where the middle and maximum of the window is, and send that directly into the FFT without swapping the first and last halves, then if you examine the phase, you will see a phase shift of +/- pi (doesn't matter which, since they are 2*pi apart) added to *only* the odd numbered values of X[k]. it's not just a display thing. it is also an analysis thing. if phase continuity is important (and if you're bothering to unwrap phase, continuity *is* important) then it is necessary to swap the first and last halves of the data before it goes into the FFT. that's how you avoid that icky problem. r b-j
From: Greg Heath on 27 Jun 2010 11:41 On Jun 26, 9:54 pm, robert bristow-johnson <r...(a)audioimagination.com> wrote: > On Jun 24, 5:48 pm, "fisico32" <marcoscipioni1(a)n_o_s_p_a_m.gmail.com> > wrote: > > > >On Jun 24, 5:12=A0pm, "fisico32" <marcoscipioni1(a)n_o_s_p_a_m.gmail.com> > ... > > >> why not? > > r b-j said (with spelling correction) > > > >you didn't swap the two halves with fftshift(). > > > >r b-j > > > Actually, on page 101 of Understanding digital signal processing by Richard > > Lyon , it is said (at the bottom) that " the particular pattern of pi and > > -pi values is an artifact of the software used to generate that figure. A > > different software package may show a different pattern.... as long as the > > nonzero phase samples are either +pi or -pi the phase results will be > > correct" > > > Is this related to the fftshift you are mentioning? No, it is not. In addition, it is not related to your problem either. > i dunno if Rick's thing is related until i dig the book out of the > correct box (since moving it from Waltham Mass back to Vermont, all of > my books are in boxes). > > if Rick is saying what i think you are crediting him for saying, then > i think that Rick is sorta incorrect. this *is* directly related to > failing to use fftshift() (or it's counterpart in whatever language or > package you are using) before applying the FFT. No, it is not. > if you have a vector > of data (with indices 0 to N-1) that is extracted from some continuous > stream of data much longer than N, and if you apply a window (like the > Hann or Hamming or Kaiser or whatever) to that vector such that the > middle of that vector (around index N/2) is where the middle and > maximum of the window is, and send that directly into the FFT without > swapping the first and last halves, then if you examine the phase, you > will see a phase shift of +/- pi (doesn't matter which, since they are > 2*pi apart) added to *only* the odd numbered values of X[k]. > > it's not just a display thing. it is also an analysis thing. if > phase continuity is important (and if you're bothering to unwrap > phase, continuity *is* important) then it is necessary to swap the > first and last halves of the data before it goes into the FFT. that's > how you avoid that icky problem. For the OP's particular problem, all of this is irrelevant. His posted example was clear all, clc f = [0 1 2 3 3 2 1]' ; F = fft(f); realF = real(F); imagF = imag(F); phaseF = angle(F); wrongphase = atan(imagF./realF); rightphase = atan2(imagF,realF); summary1 = [f F realF imagF phaseF wrongphase rightphase] % f F realF imagF phaseF wrongphase rightphase % 0 12 12 0 0 0 0 % 1 -5.0489 -5.0489 0 3.1416 0 3.1416 % 2 -0.30798 -0.30798 0 3.1416 0 3.1416 % 3 -0.6431 -0.6431 0 3.1416 0 3.1416 % 3 -0.6431 -0.6431 0 3.1416 0 3.1416 % 2 -0.30798 -0.30798 0 3.1416 0 3.1416 % 1 -5.0489 -5.0489 0 3.1416 0 3.1416 disp('Even if the imaginary component is just floating point error:') F = F + i*eps*rand(7,1); realF = real(F); imagF = imag(F); phaseF = angle(F); wrongphase = atan(imagF./realF); rightphase = atan2(imagF,realF); summary2 = [realF imagF phaseF wrongphase rightphase] % realF imagF phaseF wrongphase rightphase % 12 2.1097e-016 1.7581e-017 1.7581e-017 1.7581e-017 % -5.0489 5.1323e-017 3.1416 -1.0165e-017 3.1416 % -0.30798 1.3475e-016 3.1416 -4.3752e-016 3.1416 % -0.6431 1.0791e-016 3.1416 -1.678e-016 3.1416 % -0.6431 1.9791e-016 3.1416 -3.0774e-016 3.1416 % -0.30798 1.6922e-016 3.1416 -5.4945e-016 3.1416 % -5.0489 1.0136e-016 3.1416 -2.0075e-017 3.1416 disp(['Therefore the OPs problem is not recognizing that phase is'; ' the result of the atan2 fucntion, not the atan function !']) Hope this helps. Greg
From: Greg Heath on 27 Jun 2010 11:51
On Jun 26, 4:55 am, "Ron N." <rhnlo...(a)yahoo.com> wrote: > On Jun 24, 2:12 pm, "fisico32" <marcoscipioni1(a)n_o_s_p_a_m.gmail.com> > wrote: > > > the fft of a rectangular, even, symmetric sequence show a nonzero real part > > and a zero imaginary part. All good so far. > > > However the phase spectrum is nonzero: zero at some frequencies, pi at some > > frequencies , -pi at some others.... > > > The phase spectrum is given by atan(Imag(fft)/real(fft)), so it should give > > zero.... > > Assuming the OP isn't an AI bot, it looks like I need to > add another misconception to my FFT misconceptions page, > that the phase of an FFT result near the size of the numerical > errors in an FFT computation is relevant. Also add the misconception that caused this thread: fft phase is obtained using atan instead of atan2. Hope this helps. Greg |