DSPRelated.com
Forums

FFT convolution giving different results from convolution

Started by Michel Rouzic July 25, 2005

Michel Rouzic wrote:
> it's ok, i'm used to be confused. but to make it sure i got it right, > i'll take the example i gave before to see if i got it right. > > so I got my short signal, of length 3, that I have to zero pad to 8, > right? > > and my long signal, of length 2,103,154, has to be cut into 525,789 > blocks of length 4, each zero-padded to 8, right? > > and as for you were saying the the last half of the last block, i think > you meant I didn't have to add it to anything and just have to use it > as the last samples of my output signal which will thus have a length > of 2,103,156, which is not different in anyway to way i was thinkin > about.
Sounds good; go for it. Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein

Jerry Avins wrote:
> Rune Allnor wrote: > > > ... I would prefer a pseudocode that has no > > similarity to any existing programming languages. If pseudocode > > mimices a language, it could be seen as an indication that there > > is a "best" language for the algorithm. > > > > Actually, I saw that Golub & van Loan basically used matlab as their > > pseudocode language in their 3rd edition of the book on matrix > > computations. The pseudocode in that book *is* relatively easy to read, > > > > and matlab *is* well suited for those types of algorithms... hey, did > > I just contradict my first paragraph? > > Maybe not. Think of a pseudocode as a pidgin language.
Maybe, but I still don't like source code as documentation of algorithms. All programming languages have their idiosyncracities. Choosing, say, matlab as the language of choise, might inspire people to write in matlab-adapted lingo, with "vectorization" and all that. While those things are nice to know when actually writing matlab programs, it's just smoke and mirrors when trying to understand or document algorithms. Better, then, to have something that is clearly pseudocode and have no relations to any programming language.
> The closer the > linguistic roots of the people among whom the pidgin develops, the more > like a variant of that language will it become. Esperanto, although > completely artificial, is nevertheless largely Romance. It might make a > good linguistic "pseudotongue". Among earthlings, Klingon would not.
Hmmm.... fortran 66 "spaghetti style" source code isn't much better than Klingon... Did you read Parks & McClellan's paper on FIR filter design? Tribolet's paper on phase unwrapping? Gray & Markel's paper on the design of elliptic IIR filters? 90% of the work when reading those papers is about sorting out the programming language and programming style. Rune
Rune Allnor wrote:
> > Jerry Avins wrote: > >>Rune Allnor wrote: >> >> >>> ... I would prefer a pseudocode that has no >>>similarity to any existing programming languages. If pseudocode >>>mimices a language, it could be seen as an indication that there >>>is a "best" language for the algorithm. >>> >>>Actually, I saw that Golub & van Loan basically used matlab as their >>>pseudocode language in their 3rd edition of the book on matrix >>>computations. The pseudocode in that book *is* relatively easy to read, >>> >>>and matlab *is* well suited for those types of algorithms... hey, did >>>I just contradict my first paragraph? >> >>Maybe not. Think of a pseudocode as a pidgin language. > > > Maybe, but I still don't like source code as documentation of > algorithms. All programming languages have their idiosyncracities. > Choosing, say, matlab as the language of choise, might inspire > people to write in matlab-adapted lingo, with "vectorization" > and all that. While those things are nice to know when actually > writing matlab programs, it's just smoke and mirrors when trying > to understand or document algorithms. > > Better, then, to have something that is clearly pseudocode and have > no relations to any programming language. > > >>The closer the >>linguistic roots of the people among whom the pidgin develops, the more >>like a variant of that language will it become. Esperanto, although >>completely artificial, is nevertheless largely Romance. It might make a >>good linguistic "pseudotongue". Among earthlings, Klingon would not. > > > Hmmm.... fortran 66 "spaghetti style" source code isn't much better > than Klingon... Did you read Parks & McClellan's paper on FIR filter > design? Tribolet's paper on phase unwrapping? Gray & Markel's paper on > the design of elliptic IIR filters? 90% of the work when reading > those papers is about sorting out the programming language and > programming style.
It's partly a matter of familiarity. My first programming language was Fortran II (flys had buttons when I started wearing pants), so I may have it easier than you do. I would give good odds that you would prefer Fortran to Forth, at least at first. Have you ever tried to read Russell and Whitehead's "Principia Mathematica"? Oof! Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������

Jerry Avins wrote:
> Rune Allnor wrote: > > > > Jerry Avins wrote: > > > >>Rune Allnor wrote: > >> > >> > >>> ... I would prefer a pseudocode that has no > >>>similarity to any existing programming languages. If pseudocode > >>>mimices a language, it could be seen as an indication that there > >>>is a "best" language for the algorithm. > >>> > >>>Actually, I saw that Golub & van Loan basically used matlab as their > >>>pseudocode language in their 3rd edition of the book on matrix > >>>computations. The pseudocode in that book *is* relatively easy to read, > >>> > >>>and matlab *is* well suited for those types of algorithms... hey, did > >>>I just contradict my first paragraph? > >> > >>Maybe not. Think of a pseudocode as a pidgin language. > > > > > > Maybe, but I still don't like source code as documentation of > > algorithms. All programming languages have their idiosyncracities. > > Choosing, say, matlab as the language of choise, might inspire > > people to write in matlab-adapted lingo, with "vectorization" > > and all that. While those things are nice to know when actually > > writing matlab programs, it's just smoke and mirrors when trying > > to understand or document algorithms. > > > > Better, then, to have something that is clearly pseudocode and have > > no relations to any programming language. > > > > > >>The closer the > >>linguistic roots of the people among whom the pidgin develops, the more > >>like a variant of that language will it become. Esperanto, although > >>completely artificial, is nevertheless largely Romance. It might make a > >>good linguistic "pseudotongue". Among earthlings, Klingon would not. > > > > > > Hmmm.... fortran 66 "spaghetti style" source code isn't much better > > than Klingon... Did you read Parks & McClellan's paper on FIR filter > > design? Tribolet's paper on phase unwrapping? Gray & Markel's paper on > > the design of elliptic IIR filters? 90% of the work when reading > > those papers is about sorting out the programming language and > > programming style. > > It's partly a matter of familiarity. My first programming language was > Fortran II (flys had buttons when I started wearing pants), so I may > have it easier than you do. I would give good odds that you would prefer > Fortran to Forth, at least at first. Have you ever tried to read Russell > and Whitehead's "Principia Mathematica"? Oof!
I do read not-entirely-the-latest-or-the-hottest material, from time to time. Rayleigh's "Theory of Sound", originally published in... was it 1887? The Dover reprint is from 1945. After JASA came out in electronic form on CD, I spent a lot of time reading stuff from the 60ies. It's a different style of writing, a different vocabulary, the presentations were based on different theoretical concepts... it made me aware of what language and presentation means for getting a message through. While that sort of stuff is fascinating, decoding programs from that age, in the contemporary programming language and -style, is no fun at all. Rune
Rune Allnor wrote:

> I do read not-entirely-the-latest-or-the-hottest material, from time > to time. Rayleigh's "Theory of Sound", originally published in... was > it 1887? The Dover reprint is from 1945. After JASA came out in > electronic form on CD, I spent a lot of time reading stuff from the > 60ies. It's a different style of writing, a different vocabulary, > the presentations were based on different theoretical concepts... > it made me aware of what language and presentation means for > getting a message through.
In Principia Mathematica, every two pages of symbols is leavened with about half a dozen words. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
I did it, and it's not working properly, it's mostly returning infinite
values. you can check it here
http://groups-beta.google.com/group/comp.dsp/browse_frm/thread/d835f0fc55793755/4891fad562b4bcb3?lnk=st&q=&rnum=1&hl=en#4891fad562b4bcb3
Bob Cain wrote:
> Michel Rouzic wrote: > > it's ok, i'm used to be confused. but to make it sure i got it right, > > i'll take the example i gave before to see if i got it right. > > > > so I got my short signal, of length 3, that I have to zero pad to 8, > > right? > > > > and my long signal, of length 2,103,154, has to be cut into 525,789 > > blocks of length 4, each zero-padded to 8, right? > > > > and as for you were saying the the last half of the last block, i think > > you meant I didn't have to add it to anything and just have to use it > > as the last samples of my output signal which will thus have a length > > of 2,103,156, which is not different in anyway to way i was thinkin > > about. > > Sounds good; go for it. > > > Bob > -- > > "Things should be described as simply as possible, but no > simpler." > > A. Einstein
in article 1123777297.090480.129500@f14g2000cwb.googlegroups.com, Michel
Rouzic at Michel0528@yahoo.fr wrote on 08/11/2005 12:21:

> I did it, and it's not working properly, it's mostly returning infinite > values. you can check it here > http://groups-beta.google.com/group/comp.dsp/browse_frm/thread/d835f0fc5579375 > 5/4891fad562b4bcb3?lnk=st&q=&rnum=1&hl=en#4891fad562b4bcb3
i don't think that i want to look at this, but all i can say is that (this is the first i looked at this). if the input to the FFT is finite, and if none of the output bins equal zero, i don't understand any reason that you had to divide by zero or execute a function that would return an INF.
> Bob Cain wrote: >> Michel Rouzic wrote: >>> it's ok, i'm used to be confused. but to make it sure i got it right, >>> i'll take the example i gave before to see if i got it right. >>> >>> so I got my short signal, of length 3, that I have to zero pad to 8, >>> right? >>> >>> and my long signal, of length 2,103,154, has to be cut into 525,789 >>> blocks of length 4, each zero-padded to 8, right?
4 sample blocks??? you don't want any slope in your frequency response, do you?
>>> and as for you were saying the the last half of the last block, i think >>> you meant I didn't have to add it to anything and just have to use it >>> as the last samples of my output signal which will thus have a length >>> of 2,103,156, which is not different in anyway to way i was thinkin >>> about. >> >> Sounds good; go for it.
-- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."