# FFT convolution giving different results from convolution

Started by 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

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

Jerry
--
Engineering is the art of making what you want from things you can get.
&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
```
```
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

Jerry
--
Engineering is the art of making what you want from things you can get.
&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
```
```I did it, and it's not working properly, it's mostly returning infinite
values. you can check it here
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
>
> 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

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