Reply by robert bristow-johnson August 11, 20052005-08-11
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."
Reply by Michel Rouzic August 11, 20052005-08-11
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
Reply by Rune Allnor August 3, 20052005-08-03

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
Reply by Jerry Avins August 3, 20052005-08-03
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. �����������������������������������������������������������������������
Reply by Jerry Avins August 3, 20052005-08-03
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. �����������������������������������������������������������������������
Reply by Rune Allnor August 3, 20052005-08-03

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
Reply by Bob Cain July 31, 20052005-07-31

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
Reply by Michel Rouzic July 30, 20052005-07-30
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.

i dont think I need to ask about the rest of what has to be done cuz i
think i understood the rest of what has to be done.

Bob Cain wrote:
> Michel Rouzic wrote: > > ok thank you now that's really what i wanted to know from the start of > > this thread. and as for overlap add or save, well, overlap-add is the > > only one i understood, so it is the one i'm going to implement. thank > > you very much for help > > Actually, on rereading it I see that I was quite wrong about > the lengths to be used in OA/S; don't know what I was > thinking about. > > The short argument, M, is zero extended to the first power > of two greater than or equal to twice it's length and the > long argument, L, is processed in blocks of half that length > zero padded to that length. You seem to understand the > processing that is then applied. The extra half block at > the end, catenated to the output rather than added to the > next buffer, will accomodate the M+L-1 result and then some. > > Hope I haven't utterly confused you. > > > Bob > -- > > "Things should be described as simply as possible, but no > simpler." > > A. Einstein
Reply by Bob Cain July 30, 20052005-07-30

Michel Rouzic wrote:
> ok thank you now that's really what i wanted to know from the start of > this thread. and as for overlap add or save, well, overlap-add is the > only one i understood, so it is the one i'm going to implement. thank > you very much for help
Actually, on rereading it I see that I was quite wrong about the lengths to be used in OA/S; don't know what I was thinking about. The short argument, M, is zero extended to the first power of two greater than or equal to twice it's length and the long argument, L, is processed in blocks of half that length zero padded to that length. You seem to understand the processing that is then applied. The extra half block at the end, catenated to the output rather than added to the next buffer, will accomodate the M+L-1 result and then some. Hope I haven't utterly confused you. Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein
Reply by Michel Rouzic July 29, 20052005-07-29
ok thank you now that's really what i wanted to know from the start of
this thread. and as for overlap add or save, well, overlap-add is the
only one i understood, so it is the one i'm going to implement. thank
you very much for help

Bob Cain wrote:
> Michel Rouzic wrote: > > OK, so I see that my problem has nothing to do with the length of my > > signals. so, do you have an idea on what I gotta do so I obtian a M+L-1 > > length output signal without the time-domain aliasing problem that I > > can't get rid of? > > If you want to do it in one shot, pad both with zeros to the > first power of two greater than or equal to M+L-1. > > If you want to do it more efficiently, use overlap add or > overlap save with the small one, M, padded to the next power > of two and the longer, L, padded to the next power of two > greater than M+L-1. For OA/S you may need to do a bit of > studying. While not terribly difficult, it's a bit more > involved than should be described here. > > As to choosing among the two ways of doing overlap, add is a > bit easier to understand and save is a bit more efficient. > > > Bob > -- > > "Things should be described as simply as possible, but no > simpler." > > A. Einstein