Sign in

username or email:

password:



Not a member?
Forgot your password?

Search compdsp



Search tips


Discussion Groups

Free Online Books

See Also

Embedded SystemsFPGA

Discussion Groups | Comp.DSP | The inherent periodicity of the Discrete Fourier Transform

There are 59 messages in this thread.

You are currently looking at messages 1 to .


Is this discussion worth a thumbs up?

0

The inherent periodicity of the Discrete Fourier Transform - robert bristow-johnson - 2011-02-01 02:05:00

all right, i am changing the title of the thread.  i'm even starting
it anew as a thread (without reference to the other thread) so that it
gets threaded separately.

also, because i don't trust Google Groups, i am emailing this to Eric
so that he can read it without the 3D and A0 crap and so that i have a
record of what i was posting in case GG truncates the post again.


On Jan 31, 4:12 pm, eric.jacob...@ieee.org (Eric Jacobsen) wrote:
> On Fri, 28 Jan 2011 16:12:05 -0800 (PST), robert bristow-johnson
>
> >i just want someone (other than Eric, now, because i don't wanna read
> >him repeat the wrong answer) to tell me what the correct answer is to
> >this:

For the record, here is the question that I wanted Eric and any
inherent periodicity deniers (perhaps Dale) to answer.  Eric did
eventually answer it, but incorrectly (and he seems to be sticking to
it), so I find it difficult to proceed in sharpening the point.  The
multiple-choice question is this:

____________________________________________________________________

Let the DFT of x[n] be defined as:

            N-1
    X[k] =  SUM{ x[n] e^(-i*2*pi*n*k/N) }
            n=0

For the moment, we don't care whether or not you want to define X[k]
for integers k outside of the interval 0 <= k < N .  Maybe X[k]
exists out there or maybe not.  So ...

Given x[n], with its DFT X[k], what is y[n], the inverse DFT of

     Y[k]  =  X[k] * e^(-j*2*pi*k*m/N)

where m is an integer?



Is it

(A)  y[n]  =  x[n-m]

where

            N-1
   x[n]  =  SUM{ X[k] * b_k[n] }
            k=0

and  b_k[n]  =  (1/N) * e^(i*2*pi*k*n/N)  ?



Or is it

(B)  y[n]  =  x[n-m]

where

            N-1
   x[n]  =  SUM{ X[k] * b_k[n] }
            k=0

and  b_k[n]  =  (1/N) * e^(i*2*pi*k*n/N) * (u[n]-u[n-N])

and where u[n]-u[n-N] is a rectangular window defined by the
unit step u[n] = 1 for n >= 0  and  0 otherwise ?



Or is it

(C)  y[n]  =  x[ (n-m)mod_N ]

where

            N-1
   x[n]  =  SUM{ X[k] * b_k[n] }
            k=0

and  b_k[n]  =  (1/N) * e^(i*2*pi*k*n/N) * (u[n]-u[n-N])

and where  (n)mod_N = n - N*floor(n/N)

and floor(v) is the largest integer not exceeding the real number v ?



Or is it

(D)  none of the above ?


____________________________________________________________________

The correct answers are (A) and (C).  (B) is an incorrect answer and
therefore cannot be equivalent to (A) and (C).


> From my perspective you've not demonstrated that anything I've written
> is wrong.

you keep saying that A, B, and C are all equivalent.  they're not.  A
and C are equivalent (but C has klunky notation that must be inserted
to make it correct) and B yields a different result for any m <> 0.

>   I've posed a number of questions to you which have gone
> unanswered, and you've not responded to any of the examples I've
> provided demonstrating the utility of alternative points of view.
> You've repeated, despite my attempts at gaining clarification, the
> same A,B, C selection without addressing my questions or examples.
>
> So here's a repeat of a basic question, posed quite a while back:
>
> If the outputs are identical for the same input and all the
> computations are the same, is there some way that they wouldn't be
> equivalent?

i'll accept the premise for A and C, but not for B.  let's first get
this premise straightened out.  then i think i can answer it without
tripping all over myself.

> You indicated in your description of A, B, and C that the outputs were
> essentially identical for the same input,

no, i repeatedly indicated that the output of B was not essentially
identical to A and C (except if m=0).

let m=1, then for

(A)   y[0] = x[-1] = x[N-1]

(B)   y[0] = 0

(C)   y[0] = x[(0-1)mod_N] = x[N-1]


B is not the same as A or C.  (oh, i s'pose it could be the same if
x[N-1] happened to be 0.)


> and you've not shown how any
> of the computations change (not that it would matter if the outputs
> were unaffected).

we gotta get past this error before i can understand how to respond to
you, Eric.

if we can get past this error, i'll be able to point out a _negative_
utility (that is, a pitfall or problem requiring a workaround) to NOT
assuming the periodic extension and i will, again, ask "what utility
is there in defining the basis functions to not be periodic with
period N?"

> It should be noted that the case of the input vector being treated as
> a single period of a repeating sequence of length N is, I'd argue,
> probably one of the rarest forms of practical application of the DFT.

so convolution using the DFT is rare?

i've *never* said that the input data came from a repeating sequence
in general, just that the DFT treats it as if it is a single period of
a periodic sequence (just as the DFS does) and the evidence of that is
with *any* operation that causes shifting of the data in either time
or frequency domains.

> This assumption would require that the input signal be perfectly phase
> locked to the sampling clock,

NO, NO, NO!

the input data can come from *anywhere*.  a periodic sequence that may
or may not have period N.  a non-periodic sequence of infinite length
(and you yank out N adjacent samples).  a finite length sequence
(perhaps even of length N).  IT DOESN'T MATTER.  the DFT doesn't know
the difference and doesn't care.  all the DFT does is exactly what the
DFS does and fits these periodic basis functions to the finite set of
input data.  fitting infinitely-long and periodic basis functions to
the finite set of input data is precisely what periodically extending
the input data is.  and the DFT does that *every* time it's used.
always.  it's an inherent property of the DFT.

but you'll notice this property *only* if you do an operation in one
domain that causes shifting in the other domain.  that shifting will
*always* be circular shifting.  always.  and circular shifting of the
data is the same thing as linear shifting of the periodically-extended
data.


--

r b-j                  r...@audioimagination.com

"Imagination is more important than knowledge."



______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Re: The inherent periodicity of the Discrete Fourier Transform - Thomas Richter - 2011-02-01 05:57:00



robert bristow-johnson schrieb:

> ____________________________________________________________________
> 
> Let the DFT of x[n] be defined as:
> 
>             N-1
>     X[k] =  SUM{ x[n] e^(-i*2*pi*n*k/N) }  (*)
>             n=0
> 
> For the moment, we don't care whether or not you want to define X[k]
> for integers k outside of the interval 0 <= k < N .  Maybe X[k]
> exists out there or maybe not.  So ...

Allow me to jump in here for a moment as a mathematician. Not as a 
signal processing expert. The *important* point here is that the above 
formal definition is *not* the definition of an operator on a functional 
space, so the question on its inverse is ill-posed. For defining an 
operator, you *must* define its domain, and as soon as you do that 
properly, the answer to your question is immediate.

Thus, saying "..we do not define X[k] for k outside of the interval..." 
makes the question ill-posed, and there is no correct answer because it 
is an incorrect question. What is the function space the sum operates on 
  is more than a technicality, as you see here demonstrated.

You can ask the following questions:

A) Consider the sum (*) and define this on l^2(Z_N), the l^2-summable 
functions on the ring Z_n. This is equivalent to saying we're looking at 
periodic series (or discrete functions), periodic modulo N, and you get 
one answer.

B) Consider the sum (*) and define this on the l^2(Z) functions on Z 
with support in [0..N), i.e. on functions that are zero outside the 
interval. Then you get a different answer for the inverse, simply 
because it's a different operator.

IOW, you're probably missing the 1-0-1 of functional analysis. Define 
your operator properly, and you get a proper answer. With ill-posed 
problems, no answer at all. The *domain* is *essential* and not just a 
technicality. Answer the question on the domain, and you'll find the 
answer to your question. You *cannot* ignore this question as you try to.

Greetings,
	Thomas
______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Re: The inherent periodicity of the Discrete Fourier Transform - Clay - 2011-02-01 10:41:00


Hello Robert,

In the vein of what T. Richter wrote, I can define my DFT as operating
on finite length vectors (whose components may be complex valued)
where my DFT operator becomes a finite dimension orthogonal matrix.
Then the inverse DFT operator is simply the transpose of the matrix
apart from some scale factors. In this approach no use is made of
values outside of my domain or requires a redimensioning of my
vectors. So a DFT computation does not inherently assume peridicity
because I didn't need peridicity to do the computation.

So even if you find a way to define the DFT using a periodicity
requirement, it still doesn't prove that it has to inherently assume
periodicity since a way to calculate it can be had without
periodicity. Can you show there is no way to do a DFT calculation
without assuming peridicity?


Clay





______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Re: The inherent periodicity of the Discrete Fourier Transform - Thomas Richter - 2011-02-01 11:06:00

Clay schrieb:
> 
> Hello Robert,
> 
> In the vein of what T. Richter wrote, I can define my DFT as operating
> on finite length vectors (whose components may be complex valued)
> where my DFT operator becomes a finite dimension orthogonal matrix.

That's another option, of course, and also makes the problem well-defined.

> Then the inverse DFT operator is simply the transpose of the matrix
> apart from some scale factors. 

Correct. It is the mapping of a finite-dimensional space to another 
finite dimensional space.

> So even if you find a way to define the DFT using a periodicity
> requirement, it still doesn't prove that it has to inherently assume
> periodicity since a way to calculate it can be had without
> periodicity.

The question of "periodicity or not" is not that the DFT has to "assume 
it". Rather, you can define the DFT *on* a periodic function space, then 
get a well-defined operator, and this operator then has an inverse. You 
need not. You can carry out the DFT sum on any set of N numbers, but 
just writing down the sum doesn't define an operator.

> Can you show there is no way to do a DFT calculation
> without assuming peridicity?

Of course there are ways. You just gave one. But C^N, the set of 
N-dimensional complex vectors, is identical to the l^2(Z_N), the set of 
complex-valued, N-periodic discrete functions on N points. Thus, the 
question is rather, "do you want to look at it this way ?".

Hope this helps,

	Thomas



______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Re: The inherent periodicity of the Discrete Fourier Transform - Clay - 2011-02-01 12:03:00

>
> > Can you show there is no way to do a DFT calculation
> > without assuming peridicity?
>
> Of course there are ways. You just gave one.

That was my point.


> But C^N, the set of
> N-dimensional complex vectors, is identical to the l^2(Z_N), the set of
> complex-valued, N-periodic discrete functions on N points. Thus, the
> question is rather, "do you want to look at it this way ?".
>

This is the crux as I understand it of Robert's debate. How do we want
or wish to look at it? Although it is often convenient to invoke
peridicity when talking about DFTs on discrete functions derived from
continuous ones via bandlimiting and periodic sampling. But not all
data comes from such sources and we can DFT that data without even
thinking about periodicity, so the implication of this thread's title
that DFTs imply peridicity is flawed.

Thanks,
Clay


______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Re: The inherent periodicity of the Discrete Fourier Transform - Richard Dobson - 2011-02-01 12:42:00

On 01/02/2011 17:03, Clay wrote:
..
>> But C^N, the set of
>> N-dimensional complex vectors, is identical to the l^2(Z_N), the set of
>> complex-valued, N-periodic discrete functions on N points. Thus, the
>> question is rather, "do you want to look at it this way ?".
>>
>
> This is the crux as I understand it of Robert's debate. How do we want
> or wish to look at it? Although it is often convenient to invoke
> peridicity when talking about DFTs on discrete functions derived from
> continuous ones via bandlimiting and periodic sampling. But not all
> data comes from such sources and we can DFT that data without even
> thinking about periodicity, so the implication of this thread's title
> that DFTs imply peridicity is flawed.
>


Perhaps it should be "the inherent potential periodicity..."?

I ~love~ the way that that maths (notwithstanding my limited 
understanding of it) all boils down to "do you want to look at it this 
way ?". Maths, philosophy and linguistics (and maybe art too) all rolled 
into one package. But shh, don't tell anyone maths is a humanities 
subject, they'll cut all its funding.


Richard Dobson


______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Re: The inherent periodicity of the Discrete Fourier Transform - Eric Jacobsen - 2011-02-01 13:00:00

On Tue, 1 Feb 2011 09:03:10 -0800 (PST), Clay <c...@claysturner.com>
wrote:

>>
>> > Can you show there is no way to do a DFT calculation
>> > without assuming peridicity?
>>
>> Of course there are ways. You just gave one.
>
>That was my point.
>
>
>> But C^N, the set of
>> N-dimensional complex vectors, is identical to the l^2(Z_N), the set of
>> complex-valued, N-periodic discrete functions on N points. Thus, the
>> question is rather, "do you want to look at it this way ?".
>>
>
>This is the crux as I understand it of Robert's debate. How do we want
>or wish to look at it? Although it is often convenient to invoke
>peridicity when talking about DFTs on discrete functions derived from
>continuous ones via bandlimiting and periodic sampling. But not all
>data comes from such sources and we can DFT that data without even
>thinking about periodicity, so the implication of this thread's title
>that DFTs imply peridicity is flawed.
>
>Thanks,
>Clay

And this has been my point as well, that it boils down to how one
wishes to look at it or think about it.   The DFT itself is
unaffected, the outputs are the same regardless, but if thinking about
it one way or other helps somebody to understand it better, I think
that's a good thing!



Eric Jacobsen
http://www.ericjacobsen.org
http://www.dsprelated.com/blogs-1//Eric_Jacobsen.php
______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Re: The inherent periodicity of the Discrete Fourier Transform - Eric Jacobsen - 2011-02-01 13:33:00

Some others have already chimed in, and I'm in general agreement with
them, but I'll respond here as well just for clarity on my own
thoughts.

On Mon, 31 Jan 2011 23:05:57 -0800 (PST), robert bristow-johnson
<r...@audioimagination.com> wrote:

>
>all right, i am changing the title of the thread.  i'm even starting
>it anew as a thread (without reference to the other thread) so that it
>gets threaded separately.
>
>also, because i don't trust Google Groups, i am emailing this to Eric
>so that he can read it without the 3D and A0 crap and so that i have a
>record of what i was posting in case GG truncates the post again.
>
>
>On Jan 31, 4:12 pm, eric.jacob...@ieee.org (Eric Jacobsen) wrote:
>> On Fri, 28 Jan 2011 16:12:05 -0800 (PST), robert bristow-johnson
>>
>> >i just want someone (other than Eric, now, because i don't wanna read
>> >him repeat the wrong answer) to tell me what the correct answer is to
>> >this:
>
>For the record, here is the question that I wanted Eric and any
>inherent periodicity deniers (perhaps Dale) to answer.  Eric did
>eventually answer it, but incorrectly (and he seems to be sticking to
>it), so I find it difficult to proceed in sharpening the point.  The
>multiple-choice question is this:
>
>____________________________________________________________________
>
>Let the DFT of x[n] be defined as:
>
>            N-1
>    X[k] =  SUM{ x[n] e^(-i*2*pi*n*k/N) }
>            n=0
>
>For the moment, we don't care whether or not you want to define X[k]
>for integers k outside of the interval 0 <= k < N .  Maybe X[k]
>exists out there or maybe not.  So ...
>
>Given x[n], with its DFT X[k], what is y[n], the inverse DFT of
>
>     Y[k]  =  X[k] * e^(-j*2*pi*k*m/N)
>
>where m is an integer?
>
>
>
>Is it
>
>(A)  y[n]  =  x[n-m]
>
>where
>
>            N-1
>   x[n]  =  SUM{ X[k] * b_k[n] }
>            k=0
>
>and  b_k[n]  =  (1/N) * e^(i*2*pi*k*n/N)  ?
>
>
>
>Or is it
>
>(B)  y[n]  =  x[n-m]
>
>where
>
>            N-1
>   x[n]  =  SUM{ X[k] * b_k[n] }
>            k=0
>
>and  b_k[n]  =  (1/N) * e^(i*2*pi*k*n/N) * (u[n]-u[n-N])
>
>and where u[n]-u[n-N] is a rectangular window defined by the
>unit step u[n] = 1 for n >= 0  and  0 otherwise ?
>
>
>
>Or is it
>
>(C)  y[n]  =  x[ (n-m)mod_N ]
>
>where
>
>            N-1
>   x[n]  =  SUM{ X[k] * b_k[n] }
>            k=0
>
>and  b_k[n]  =  (1/N) * e^(i*2*pi*k*n/N) * (u[n]-u[n-N])
>
>and where  (n)mod_N = n - N*floor(n/N)
>
>and floor(v) is the largest integer not exceeding the real number v ?
>
>
>
>Or is it
>
>(D)  none of the above ?
>
>
>____________________________________________________________________
>
>The correct answers are (A) and (C).  (B) is an incorrect answer and
>therefore cannot be equivalent to (A) and (C).
>
>
>> From my perspective you've not demonstrated that anything I've written
>> is wrong.
>
>you keep saying that A, B, and C are all equivalent.  they're not.  A
>and C are equivalent (but C has klunky notation that must be inserted
>to make it correct) and B yields a different result for any m <> 0.

>>   I've posed a number of questions to you which have gone
>> unanswered, and you've not responded to any of the examples I've
>> provided demonstrating the utility of alternative points of view.
>> You've repeated, despite my attempts at gaining clarification, the
>> same A,B, C selection without addressing my questions or examples.
>>
>> So here's a repeat of a basic question, posed quite a while back:
>>
>> If the outputs are identical for the same input and all the
>> computations are the same, is there some way that they wouldn't be
>> equivalent?
>
>i'll accept the premise for A and C, but not for B.  let's first get
>this premise straightened out.  then i think i can answer it without
>tripping all over myself.

If the output is different, then you've somehow, and I'm actually not
sure how, changed the operation of the DFT.  Just putting a window of
length N around the basis functions won't do that, since that's how
the DFT is implemented.   IOW, if you've not changed any computations
in the DFT, then I don't know how the output has changed.   If you've
changed computations in the DFT, then you've done something other than
just restrict the operations to a length-N window.

>> You indicated in your description of A, B, and C that the outputs were
>> essentially identical for the same input,
>
>no, i repeatedly indicated that the output of B was not essentially
>identical to A and C (except if m=0).

Sorry, you've consistently said, even in this post:

(A)  y[n]  =  x[n-m]

(B)  y[n]  =  x[n-m]

Those look equivalent to me, and, as stated above, if you get a
different answer for B when m = 0 after limiting the basis functions
to the input aperture, then it seems to me that you're computing
something other than a DFT for that case.

I'm probably daft or something, but I'm just not seeing it.

>let m=1, then for
>
>(A)   y[0] = x[-1] = x[N-1]
>
>(B)   y[0] = 0
>
>(C)   y[0] = x[(0-1)mod_N] = x[N-1]
>
>
>B is not the same as A or C.  (oh, i s'pose it could be the same if
>x[N-1] happened to be 0.)
>
>
>> and you've not shown how any
>> of the computations change (not that it would matter if the outputs
>> were unaffected).
>
>we gotta get past this error before i can understand how to respond to
>you, Eric.
>
>if we can get past this error, i'll be able to point out a _negative_
>utility (that is, a pitfall or problem requiring a workaround) to NOT
>assuming the periodic extension and i will, again, ask "what utility
>is there in defining the basis functions to not be periodic with
>period N?"

So which computations change?   Viewing the DFT as a linear algebra
matrix multiplication, how does the transform matrix change in case B?
If it doesn't change, then how does the output become different for
the same input?   If it does change, how is it still a DFT?

>> It should be noted that the case of the input vector being treated as
>> a single period of a repeating sequence of length N is, I'd argue,
>> probably one of the rarest forms of practical application of the DFT.
>
>so convolution using the DFT is rare?

Not at all.  I meant the cases in practice where the input sequence is
a single period of a repeating sequence, i.e., x(n) is a single period
of an existing repeating sequence.   Not in concept, in practice.
i.e., x(n) was a single period removed from a longer sequence z(n).  I
don't think that happens very often and I explained that, for
practical applications working on samples collected from some
real-world measurement, it would mean that the sequence had to be
phase-locked with the ADC.

>i've *never* said that the input data came from a repeating sequence
>in general, just that the DFT treats it as if it is a single period of
>a periodic sequence (just as the DFS does) and the evidence of that is
>with *any* operation that causes shifting of the data in either time
>or frequency domains.

And my point was that using that conceptual tool is most apropos for
the academic, theoretical cases where it helps to understand the
operation, and for the very rare practical cases where the data is
phase-locked to the ADC.    In most cases the data is NOT phase-locked
to the ADC, so for most applications I think viewing the aperture as
having a rectangular window is pretty practical and useful, as it
better reflects how most data is actually acquired.

So my comments were just about fitting how one thinks about the
operation to what is actually happening with the data.   I think it's
perfectly okay to think about the data being periodically extended if
it helps one get through some analysis or algorithm defnition more
quickly, but I take exception to the notion that one HAS to think of
it as periodically extended.

>> This assumption would require that the input signal be perfectly phase
>> locked to the sampling clock,
>
>NO, NO, NO!
>
>the input data can come from *anywhere*.  a periodic sequence that may
>or may not have period N.  a non-periodic sequence of infinite length
>(and you yank out N adjacent samples).  a finite length sequence
>(perhaps even of length N).  IT DOESN'T MATTER.  the DFT doesn't know
>the difference and doesn't care.

On this point we are in violent agreement.


> all the DFT does is exactly what the
>DFS does and fits these periodic basis functions to the finite set of
>input data.  fitting infinitely-long and periodic basis functions to
>the finite set of input data is precisely what periodically extending
>the input data is.  and the DFT does that *every* time it's used.
>always.  it's an inherent property of the DFT.

On this point we disagree.   Sort of.   As I've said repeatedly, or
periodically of late, I think the periodic extension point of view is
very useful, especially in helping to understand the circularity of
many operations related to the DFT.   I do not agree that it is the
only way to look at it.

>but you'll notice this property *only* if you do an operation in one
>domain that causes shifting in the other domain.  that shifting will
>*always* be circular shifting.  always.  and circular shifting of the
>data is the same thing as linear shifting of the periodically-extended
>data.

I previously provided examples, and even reiterated them once already,
that is it NOT necessary to view the data as extended, and if one does
view the data as extended then it is NOT necessary to view the basis
functions as extended.   It is NOT necessary to view EITHER as
periodically extended if a domain shift is allowed.   IOW, mix the
time domain sequence by a rotating phasor, aka, a complex sinusoid.
This does NOT involve a DFT, and the data and sinusoid can be of any
length N.   This will shift the spectrum of the time domain sequence
in a circular fashion, and no DFT is required to do this.    A DFT
will reflect that the spectrum has been circularly shifted, however.

This is a very practical thing to do in multiple access bursty or
packet-based communication systems where various terminals have
different oscillator references.   Each packet coming from a different
source into a receiver will have a different carrier frequency.   It
is not necessary to extend either the length of the received packet or
the oscillator (sinusoidal) function that mixes it to phase-lock at
baseband.   Each one can be windowed in time and the packet and
oscillator are both windowed identically, and each gets shifted in
frequency (circularly if done digitally)  even though they're isolated
in time from each other, with different reference (basis) functions
that are also isolated in time.   So the shift can be done, and is
routinely done in practice, with both the reference and the data
windowed.

The same thing happens in the DFT.


Eric Jacobsen
http://www.ericjacobsen.org
http://www.dsprelated.com/blogs-1//Eric_Jacobsen.php
______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Re: The inherent periodicity of the Discrete Fourier Transform - Greg Heath - 2011-02-01 18:16:00

On Feb 1, 2:05 am, robert bristow-johnson <r...@audioimagination.com>
wrote:
> all right, i am changing the title of the thread.  i'm even starting
> it anew as a thread (without reference to the other thread) so that it
> gets threaded separately.
>
> also, because i don't trust Google Groups, i am emailing this to Eric
> so that he can read it without the 3D and A0 crap and so that i have a
> record of what i was posting in case GG truncates the post again.
>
> On Jan 31, 4:12 pm, eric.jacob...@ieee.org (Eric Jacobsen) wrote:
>
> > On Fri, 28 Jan 2011 16:12:05 -0800 (PST), robert bristow-johnson
>
> > >i just want someone (other than Eric, now, because i don't wanna read
> > >him repeat the wrong answer) to tell me what the correct answer is to
> > >this:
>
> For the record, here is the question that I wanted Eric and any
> inherent periodicity deniers (perhaps Dale) to answer.  Eric did
> eventually answer it, but incorrectly (and he seems to be sticking to
> it), so I find it difficult to proceed in sharpening the point.  The
> multiple-choice question is this:
>
> ____________________________________________________________________
>
> Let the DFT of x[n] be defined as:
>
>             N-1
>     X[k] =  SUM{ x[n] e^(-i*2*pi*n*k/N) }
>             n=0
>
> For the moment, we don't care whether or not you want to define X[k]
> for integers k outside of the interval 0 <= k < N .  Maybe X[k]
> exists out there or maybe not.  So ...
>
> Given x[n], with its DFT X[k], what is y[n], the inverse DFT of
>
>      Y[k]  =  X[k] * e^(-j*2*pi*k*m/N)

WHOOPS! Change the "j" to an "i"?

> where m is an integer?

for   ? <= m <= ?

First you have to define the reconstruction
xr[n], 0 <= n <= N-1, via the IDFT of X[k]

xrn[n] = (1/N)*SUM(k=0,N-1){ X(k)*e^(+i*2*pi*n*k/N)}

Clearly,

xr[n] = x[n] for 0 <= n <= N-1.

To do anymore than that you have to DEFINE
BOTH x[n] and xr[n] outside of [0,N-1).

So, I think it is as simple as Thomas said previously:
The definition of a function is incomplete if the domain
is not specified.

Hope this helps.

Greg
______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Re: The inherent periodicity of the Discrete Fourier Transform - Andrew Reilly - 2011-02-01 18:30:00

On Tue, 01 Feb 2011 09:03:10 -0800, Clay wrote:

>> But C^N, the set of
>> N-dimensional complex vectors, is identical to the l^2(Z_N), the set of
>> complex-valued, N-periodic discrete functions on N points. Thus, the
>> question is rather, "do you want to look at it this way ?".
>>
>>
> This is the crux as I understand it of Robert's debate. How do we want
> or wish to look at it? Although it is often convenient to invoke
> peridicity when talking about DFTs on discrete functions derived from
> continuous ones via bandlimiting and periodic sampling. But not all data
> comes from such sources and we can DFT that data without even thinking
> about periodicity, so the implication of this thread's title that DFTs
> imply peridicity is flawed.

It's not just (or even) sampled bandlimited data that is at issue.  As 
Robert's post showed, many (all?) of the interesting properties of 
Fourier transforms, such as shift and convolution, work with circular or 
periodic results.  So it's true that you can take a DFT of N complex 
points, and re-form those complex points through the inverse DFT without 
and recourse to periodic or circular extensions, and perform additions in 
the transform domain, but that's about it.

I find many of the well known properties of the Fourier transform useful, 
so I think of the results as circular.  (Discrete systems are always 
circular, in a sense.  That's why Z-plane plots are on a circle, and why 
aliasing happens the way it does.)

Cheers,

-- 
Andrew
______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

| 1 | | 3 | 4 | 5 | 6 |