Path: news.mathworks.com!not-for-mail
From: <HIDDEN>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Time shift and FFT
Date: Tue, 25 May 2010 16:57:05 +0000 (UTC)
Organization: The MathWorks Inc
Lines: 68
Message-ID: <htgvh1$epd$1@fred.mathworks.com>
References: <hpkbtt$reg$1@fred.mathworks.com> <hpkqq5$q1t$1@fred.mathworks.com> <465c233b-da87-4969-920d-921f92410ea1@h20g2000prn.googlegroups.com> <htgp4n$od2$1@fred.mathworks.com>
Reply-To: <HIDDEN>
NNTP-Posting-Host: webapp-02-blr.mathworks.com
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: fred.mathworks.com 1274806625 15149 172.30.248.37 (25 May 2010 16:57:05 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Tue, 25 May 2010 16:57:05 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 1597503
Xref: news.mathworks.com comp.soft-sys.matlab:639145

"omegayen " <omegayen@ameritech.net> wrote in message <htgp4n$od2$1@fred.mathworks.com>...
> dbd <dbd@ieee.org> wrote in message <465c233b-da87-4969-920d-921f92410ea1@h20g2000prn.googlegroups.com>...
> > On May 24, 3:22 pm, "omegayen " <omega...@ameritech.net> wrote:
> > > dbd <d...@ieee.org> wrote in message <f080661f-69fd-447b-9610-681edac15...@q39g2000prh.googlegroups.com>...
> > > > On May 24, 12:36 pm, "omegayen " <omega...@ameritech.net> wrote:
> > >
> > > > [quoted code removed]
> > 
> > > I was just extending the original example.
> > >
> > > My new example made the signal in the time domain complex and I was merely trying to prove or disprove to myself that the Fourier Transform is only defined for real signals and not complex signals.
> > >
> > > Does this make sense?
> > >
> > > Essentially I was asking the question, can you take the Fourier transform of a complex signal which is in the time domain?
> > 
> > So what was your conclusion?
> > 
> > Did you try 0:94 for n and k? What was your conclusion?
> > 
> > Dale B. Dalrymple
> 
> Yes I tried for 0:94 for n and k, when I made the signal x and y in this case, complex
> 
> specifically I ran
> 
> n=0:94;
> x = cos(pi/4*n)+i*cos(2*pi/4*n);
> delay=2;
> y = cos(pi/4*(n-delay))+i*cos(2*pi/4*(n-delay));
> k=0:94;
> % the DFT of y is exp(-1j*2*pi*k*delay/95)
> phaseshift = exp(1j*2*pi*k*delay/95);
> ydft = fft(y);
> xdft = fft(x);
> ydft=ydft.*phaseshift;
> norm(xdft-ydft)
> % 3.0397e-014
> max( max(real(xdft)-real(ydft)), max(imag(xdft)-imag(ydft)))
> % also on the order of 10^(-14)
> y1 = ifft(ydft,'symmetric');
> subplot(211);
> plot(x);
> subplot(212);
> plot(y1);
> 
> this shows that you can't take the Fourier Transform, do the time shift, and then take the inverse Fourier Transform to get the original signal when the original signal is complex (in the time domain)

Hi, I don't think that's correct. There's nothing about the time-shift property that demands that the data is real-valued. The mistake you're making is in using the 'symmetric' flag in the inverse discrete Fourier transform. You are forcing the signal to be real-valued. You only use that flag when the Fourier transform is conjugate symmetric and you know that you should obtain a real-valued signal in the time domain, but you might get nonzero imaginary parts due to rounding errors.

n = 0:95; k = 0:95; delay =2;
y = cos(pi/4*(n-delay))+i*cos(2*pi/4*(n-delay));  
x = cos(pi/4*n)+i*cos(2*pi/4*n);
yDFT = fft(y);
xDFT = fft(x);
phaseshift = exp(1j*2*pi*k*delay/96);
y1  = yDFT.*phaseshift;
y1 = ifft(y1);
subplot(211); 
plot(real(y1),'k'); hold on;
plot(real(x),'b');
subplot(212);
plot(imag(y1),'k'); hold on;
plot(imag(x),'b'); 


Hope that helps,
Wayne