On Wed, 10 Oct 2012 00:19:50 -0400, Jerry Avins <jya@ieee.org> wrote:>On 10/9/2012 8:24 PM, Eric Jacobsen wrote: > > ... > > > Regardless there is basis for developing, deriving and understanding >> the DFT/FFT that does not require a periodic input sequence or loss of >> generality. This provides consistency with other points of view, many >> of which have been discussed here periodically in the past. > >Periodically, eh? > >JerryAnd Randy Yates wrote:>Oh puhlease! :) >-- >Randy YatesI've used that pun and others like it quite a few times in the past and nobody seemed to notice. I'm glad you guys spoke up this time. ;) Eric Jacobsen Anchor Hill Communications www.anchorhill.com
fourier transform - time domain to frequency domain and vice versa
Started by ●October 6, 2012
Reply by ●October 10, 20122012-10-10
Reply by ●October 21, 20122012-10-21
On Mon, 08 Oct 2012 23:04:41 GMT, eric.jacobsen@ieee.org (Eric Jacobsen) wrote:>On Sun, 07 Oct 2012 18:14:16 -0400, robert bristow-johnson ><rbj@audioimagination.com> wrote: > >>On 10/7/12 12:46 PM, Eric Jacobsen wrote: >>> On Sun, 7 Oct 2012 12:52:17 +0000 (UTC), mblume >>> <foobar@invalid.invalid> wrote: >>> > >> >> >>>> So it is not just a number (200 = sum(f(tsamples)), but 200 ***Hz***. >>>> Knowing that a sine wave has a frequency of 200 Hz allows to reconstruct >>>> every value of it. >>>> >>>> Another trick is that the FFT is based on the assumptions that >>>> (a) the N samples repeat over and over again continuously (x[i] = x[i+N]) >>> >>> That's an often-repeated misconception. >> >>what's the misconception? that the FFT considers that x[n+N] = x[n] or >>that it's a trick? > >It is a misconception that the derivation or understanding of the >DFT/FFT "assumes" or requires that the input vector repeats >continuously, i.e., (x[i] = x[i+N])Hi Eric, I believe only living creatures can make assumptions and the DFT is not alive. (Square root algorithms don't make judgments, logarithm operations don't have opinions, and FFT algorithms don't make assumptions.) [-Rick-]
Reply by ●October 21, 20122012-10-21
On Wed, 10 Oct 2012 15:43:21 GMT, eric.jacobsen@ieee.org (Eric Jacobsen) wrote:>On Wed, 10 Oct 2012 00:19:50 -0400, Jerry Avins <jya@ieee.org> wrote: > >>On 10/9/2012 8:24 PM, Eric Jacobsen wrote: >> >> ... >> >> > Regardless there is basis for developing, deriving and understanding >>> the DFT/FFT that does not require a periodic input sequence or loss of >>> generality. This provides consistency with other points of view, many >>> of which have been discussed here periodically in the past. >> >>Periodically, eh? >> >>Jerry > >And Randy Yates wrote: > >>Oh puhlease! :) >>-- >>Randy Yates > >I've used that pun and others like it quite a few times in the past >and nobody seemed to notice. I'm glad you guys spoke up this time. >;)I'm sorry to say, that pun flew undetected right over my head. [-Rick-]
Reply by ●October 21, 20122012-10-21
On Tue, 09 Oct 2012 15:36:10 GMT, eric.jacobsen@ieee.org (Eric Jacobsen) wrote:>On Tue, 9 Oct 2012 02:25:03 +0000 (UTC), glen herrmannsfeldt ><gah@ugcs.caltech.edu> wrote: > >>Eric Jacobsen <eric.jacobsen@ieee.org> wrote: >> >>(snip) >> >>> It is a misconception that the derivation or understanding of the >>> DFT/FFT "assumes" or requires that the input vector repeats >>> continuously, i.e., (x[i] = x[i+N]) >> >>OK, not assumes, but it is based on the solutions to a >>differential equation with periodic boundary conditions. >> >>> I know you may disagree and I'm inclined to ignore any attempt to drag >>> this into yet another discussion on the topic. Your views are well >>> known. >> >> >>-- glen > >You've mentioned that before, but I'm not directly familiar with that >treatment. There are some common approaches that assume periodicity in >order to simplify the analysis and I think these are what lead people >to believe that it is a property or requirement when using a DFT/FFT. > >It is not necessary to make that assumption, and one can do so without >a loss of generality: > >http://www.dsprelated.com/showarticle/175.phpHI Eric, One misconception that some people have is that the spectral characterisic we call "spectral leakage" is caused by, is due to, is a shortcoming of the DFT. I believe the cause of leakage is the act of sampling an analog signal, ...and it seems to me that the DFT merely quantifies, illustrates, reveals spectral leakage. The DFT is such a deep and fascinating subject. It's entertaining to try to figure out just what *is* this thing called "the DFT? What is it's "nature"? It reminds me of a line from the movie "Silence of the Lambs": "First principles, Clarice. SIMPLICITY! Read Marcus Aurelius. Of each particular thing ask: What is it in itself? What is its nature? What does he do, this man you seek?" -- Hannibal Lecter [-Rick-]
Reply by ●October 21, 20122012-10-21
On Sun, 21 Oct 2012 08:06:08 -0700, Rick Lyons <R.Lyons@_BOGUS_ieee.org> wrote:>On Tue, 09 Oct 2012 15:36:10 GMT, eric.jacobsen@ieee.org (Eric >Jacobsen) wrote: > >>On Tue, 9 Oct 2012 02:25:03 +0000 (UTC), glen herrmannsfeldt >><gah@ugcs.caltech.edu> wrote: >> >>>Eric Jacobsen <eric.jacobsen@ieee.org> wrote: >>> >>>(snip) >>> >>>> It is a misconception that the derivation or understanding of the >>>> DFT/FFT "assumes" or requires that the input vector repeats >>>> continuously, i.e., (x[i] = x[i+N]) >>> >>>OK, not assumes, but it is based on the solutions to a >>>differential equation with periodic boundary conditions. >>> >>>> I know you may disagree and I'm inclined to ignore any attempt to drag >>>> this into yet another discussion on the topic. Your views are well >>>> known. >>> >>> >>>-- glen >> >>You've mentioned that before, but I'm not directly familiar with that >>treatment. There are some common approaches that assume periodicity in >>order to simplify the analysis and I think these are what lead people >>to believe that it is a property or requirement when using a DFT/FFT. >> >>It is not necessary to make that assumption, and one can do so without >>a loss of generality: >> >>http://www.dsprelated.com/showarticle/175.php > >HI Eric, > One misconception that some people have is that >the spectral characterisic we call "spectral leakage" >is caused by, is due to, is a shortcoming of the >DFT. I believe the cause of leakage is the >act of sampling an analog signal, ...and it seems >to me that the DFT merely quantifies, illustrates, >reveals spectral leakage.I think the "leakage", i.e., the sidelobe energy, is a result of having a finite non-zero data set, specifically a "window" around the data. The transform of the window is the template for the "leakage" that gets convolved with the transform of the input. This works out for continuous or sampled signals, so the connection to sampling isn't clear to me.>The DFT is such a deep and fascinating subject. >It's entertaining to try to figure out just what >*is* this thing called "the DFT? What is it's "nature"? >It reminds me of a line from the movie "Silence of >the Lambs": > > "First principles, Clarice. SIMPLICITY! > Read Marcus Aurelius. Of each particular thing > ask: What is it in itself? What is its nature? > What does he do, this man you seek?" > -- Hannibal Lecter > >[-Rick-]Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●October 21, 20122012-10-21
On 10/21/12 10:00 AM, Rick Lyons wrote:> On Mon, 08 Oct 2012 23:04:41 GMT, eric.jacobsen@ieee.org (Eric > Jacobsen) wrote: > >> On Sun, 07 Oct 2012 18:14:16 -0400, robert bristow-johnson >> <rbj@audioimagination.com> wrote: >> >>> On 10/7/12 12:46 PM, Eric Jacobsen wrote: >>>> On Sun, 7 Oct 2012 12:52:17 +0000 (UTC), mblume >>>> <foobar@invalid.invalid> wrote: >>>> >> >>> >>> >>>>> So it is not just a number (200 = sum(f(tsamples)), but 200 ***Hz***. >>>>> Knowing that a sine wave has a frequency of 200 Hz allows to reconstruct >>>>> every value of it. >>>>> >>>>> Another trick is that the FFT is based on the assumptions that >>>>> (a) the N samples repeat over and over again continuously (x[i] = x[i+N]) >>>> >>>> That's an often-repeated misconception. >>> >>> what's the misconception? that the FFT considers that x[n+N] = x[n] or >>> that it's a trick? >> >> It is a misconception that the derivation or understanding of the >> DFT/FFT "assumes" or requires that the input vector repeats >> continuously, i.e., (x[i] = x[i+N]) > > I believe only living creatures can make assumptions > and the DFT is not alive. (Square root algorithms don't > make judgments, logarithm operations don't have opinions, > and FFT algorithms don't make assumptions.)ya know, perhaps Daniel Dennett is correct and we are *all* just automatons that merely *think* we have consciousness and self-awareness (and can make assumptions or have opinions). doesn't change the fact that the DFT periodically extends the finite data set passed to it. the misconception is the denial of the fact. the periodic extension is hidden in the trivial case that no operation causes shifting, but is exposed for all to see when some operation causing shifting (like multiplication by something non-constant) is applied. there is *no* case where an operation that shifts the data set does not display this periodic extension. if no shifting occurs and this periodicity is not apparent, that is not evidence for the lack of it. it only means that this property is moot regarding this (trivial) operation. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●October 21, 20122012-10-21
On 10/21/12 12:48 PM, robert bristow-johnson wrote:> On 10/21/12 10:00 AM, Rick Lyons wrote: >> On Mon, 08 Oct 2012 23:04:41 GMT, eric.jacobsen@ieee.org (Eric >> Jacobsen) wrote: >> >>> On Sun, 07 Oct 2012 18:14:16 -0400, robert bristow-johnson >>> <rbj@audioimagination.com> wrote: >>> >>>> On 10/7/12 12:46 PM, Eric Jacobsen wrote: >>>>> On Sun, 7 Oct 2012 12:52:17 +0000 (UTC), mblume >>>>> <foobar@invalid.invalid> wrote: >>>>> >>> >>>> >>>> >>>>>> So it is not just a number (200 = sum(f(tsamples)), but 200 ***Hz***. >>>>>> Knowing that a sine wave has a frequency of 200 Hz allows to >>>>>> reconstruct >>>>>> every value of it. >>>>>> >>>>>> Another trick is that the FFT is based on the assumptions that >>>>>> (a) the N samples repeat over and over again continuously (x[i] = >>>>>> x[i+N]) >>>>> >>>>> That's an often-repeated misconception. >>>> >>>> what's the misconception? that the FFT considers that x[n+N] = x[n] or >>>> that it's a trick? >>> >>> It is a misconception that the derivation or understanding of the >>> DFT/FFT "assumes" or requires that the input vector repeats >>> continuously, i.e., (x[i] = x[i+N]) >> >> I believe only living creatures can make assumptions >> and the DFT is not alive. (Square root algorithms don't >> make judgments, logarithm operations don't have opinions, >> and FFT algorithms don't make assumptions.) > > ya know, perhaps Daniel Dennett is correct and we are *all* just > automatons that merely *think* we have consciousness and self-awareness > (and can make assumptions or have opinions). > > doesn't change the fact that the DFT periodically extends the finite > data set passed to it. the misconception is the denial of the fact. the > periodic extension is hidden in the trivial case that no operation > causes shifting, but is exposed for all to see when some operation > causing shifting (like multiplication by something non-constant) is > applied.by this i mean: multiplication by something non-constant in one domain causing shifting in the reciprocal domain.> there is *no* case where an operation that shifts the data set does not > display this periodic extension.oh, all right, when the data set is sufficiently zero-padded, the periodicity might not be evident if the shift is small enough. this is because a zero that is wrapped around is indistinguishable from a zero shifted linearly. but it's still a zero that is wrapped around, not one shifted linearly. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●October 23, 20122012-10-23
On Sun, 21 Oct 2012 15:44:12 GMT, eric.jacobsen@ieee.org (Eric Jacobsen) wrote:>On Sun, 21 Oct 2012 08:06:08 -0700, Rick Lyons ><R.Lyons@_BOGUS_ieee.org> wrote: > >>On Tue, 09 Oct 2012 15:36:10 GMT, eric.jacobsen@ieee.org (Eric >>Jacobsen) wrote: >> >>>On Tue, 9 Oct 2012 02:25:03 +0000 (UTC), glen herrmannsfeldt >>><gah@ugcs.caltech.edu> wrote: >>> >>>>Eric Jacobsen <eric.jacobsen@ieee.org> wrote: >>>> >>>>(snip) >>>> >>>>> It is a misconception that the derivation or understanding of the >>>>> DFT/FFT "assumes" or requires that the input vector repeats >>>>> continuously, i.e., (x[i] = x[i+N]) >>>> >>>>OK, not assumes, but it is based on the solutions to a >>>>differential equation with periodic boundary conditions. >>>> >>>>> I know you may disagree and I'm inclined to ignore any attempt to drag >>>>> this into yet another discussion on the topic. Your views are well >>>>> known. >>>> >>>> >>>>-- glen >>> >>>You've mentioned that before, but I'm not directly familiar with that >>>treatment. There are some common approaches that assume periodicity in >>>order to simplify the analysis and I think these are what lead people >>>to believe that it is a property or requirement when using a DFT/FFT. >>> >>>It is not necessary to make that assumption, and one can do so without >>>a loss of generality: >>> >>>http://www.dsprelated.com/showarticle/175.php >> >>HI Eric, >> One misconception that some people have is that >>the spectral characterisic we call "spectral leakage" >>is caused by, is due to, is a shortcoming of the >>DFT. I believe the cause of leakage is the >>act of sampling an analog signal, ...and it seems >>to me that the DFT merely quantifies, illustrates, >>reveals spectral leakage. > >I think the "leakage", i.e., the sidelobe energy, is a result of >having a finite non-zero data set, specifically a "window" around the >data. The transform of the window is the template for the "leakage" >that gets convolved with the transform of the input. > >This works out for continuous or sampled signals, so the connection to >sampling isn't clear to me.Hi Eric, I didn't explain myself very well. By "the act of sampling" I meant collecting a finite-length of signal sample values. We're in agreement Eric. See Ya', [-Rick-]
