# ButterWOrth filter using matlab

Started by July 18, 2003
```hi everybody,

I am working on MAtlab for verification of Butterworth Filter for low
pass filter, I have written the following program for it,
N=20;%Order of Filter
fc=200;%Cut-off frequency of filter
fs=5000;%Sampling Frequency
fin=1000;%Input frequency of pure sine wave

n1=fs/fin; %No. of samples in sine value
n2=fs/fc;

i=1;
%Input Coefficients
for m=0:2*pi/n1:2*pi,
x(i)=sin(m);
i=i+1;
end;
%Filter Coefficients
i=1;

for m=0:n2:2*fc,
y(i)=1/(1+((m/fc).^(2*N)));
i=i+1;
end;
%Output Coefficients.
z=conv(x,y1);

If the above program is correct and the output obtained is correct, I
am able go forward with the same program to be implemented in ADSP
21061 EZKit Lite.
```
```Hello Suman,

While I'm not a Matlab guy, it appears (If I read your program correctly)
that you are convolving your data with an FIR filter whose tap values are
the mangitude of a Butterworth filter. If this is the case, it will fail for
several reasons. One: the Butterworth filter is an IIR design. Two: the
Butterworth filter has a phase response different from what you have here.
Third: the magnitude response for a Butterworth needs a square root which is
left out. And of course the taps in an FIR filter are the impulse response
and not the frequency response.

Clay

"Suman" <suma_kin@yahoo.com> wrote in message
> hi everybody,
>
> I am working on MAtlab for verification of Butterworth Filter for low
> pass filter, I have written the following program for it,
>      N=20;%Order of Filter
>      fc=200;%Cut-off frequency of filter
>      fs=5000;%Sampling Frequency
>      fin=1000;%Input frequency of pure sine wave
>
>      n1=fs/fin; %No. of samples in sine value
>      n2=fs/fc;
>
>     i=1;
> %Input Coefficients
>     for m=0:2*pi/n1:2*pi,
>        x(i)=sin(m);
>        i=i+1;
>     end;
> %Filter Coefficients
>     i=1;
>
>     for m=0:n2:2*fc,
>         y(i)=1/(1+((m/fc).^(2*N)));
>         i=i+1;
>     end;
> %Output Coefficients.
>     z=conv(x,y1);
>
> If the above program is correct and the output obtained is correct, I
> am able go forward with the same program to be implemented in ADSP
> 21061 EZKit Lite.

```
```On Fri, 18 Jul 2003 11:31:31 -0400, "Clay S. Turner"
<physicsNOOOOSPPPPAMMMM@bellsouth.net> wrote:

>Hello Suman,
>
>While I'm not a Matlab guy, it appears (If I read your program correctly)
>that you are convolving your data with an FIR filter whose tap values are
>the mangitude of a Butterworth filter. If this is the case, it will fail for
>several reasons. One: the Butterworth filter is an IIR design. Two: the
>Butterworth filter has a phase response different from what you have here.
>Third: the magnitude response for a Butterworth needs a square root which is
>left out. And of course the taps in an FIR filter are the impulse response
>and not the frequency response.
>
>Clay

Actually, you can get a very good Butterworth response with a FIR
design.  See

http://www.dspguru.com/comp.dsp/tricks/dsn/nlp_fir.htm

for a brief description how.

>"Suman" <suma_kin@yahoo.com> wrote in message
>> hi everybody,
>>
>> I am working on MAtlab for verification of Butterworth Filter for low
>> pass filter, I have written the following program for it,
>>      N=20;%Order of Filter
>>      fc=200;%Cut-off frequency of filter
>>      fs=5000;%Sampling Frequency
>>      fin=1000;%Input frequency of pure sine wave
>>
>>      n1=fs/fin; %No. of samples in sine value
>>      n2=fs/fc;
>>
>>     i=1;
>> %Input Coefficients
>>     for m=0:2*pi/n1:2*pi,
>>        x(i)=sin(m);
>>        i=i+1;
>>     end;
>> %Filter Coefficients
>>     i=1;
>>
>>     for m=0:n2:2*fc,
>>         y(i)=1/(1+((m/fc).^(2*N)));
>>         i=i+1;
>>     end;
>> %Output Coefficients.
>>     z=conv(x,y1);
>>
>> If the above program is correct and the output obtained is correct, I
>> am able go forward with the same program to be implemented in ADSP
>> 21061 EZKit Lite.
>
>
>

Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org
```
```Hi All,

No comments on what you're doing, but how you're doing it.

suma_kin@yahoo.com (Suman) writes:

> hi everybody,
>
> I am working on MAtlab for verification of Butterworth Filter for low
> pass filter, I have written the following program for it,
>      N=20;%Order of Filter
>      fc=200;%Cut-off frequency of filter
>      fs=5000;%Sampling Frequency
>      fin=1000;%Input frequency of pure sine wave
>
>      n1=fs/fin; %No. of samples in sine value
>      n2=fs/fc;
>
>     i=1;
> %Input Coefficients
>     for m=0:2*pi/n1:2*pi,
>        x(i)=sin(m);
>        i=i+1;
>     end;

It's easier (and faster for more complex loops) to write:

x = sin(0:2*pi/n1:2*pi);

> %Filter Coefficients
>     i=1;
>
>     for m=0:n2:2*fc,
>         y(i)=1/(1+((m/fc).^(2*N)));
>         i=i+1;
>     end;

Same here:

y = 1./(1+([0:n2:2*fc].^2*N));

> %Output Coefficients.
>     z=conv(x,y1);
>
> If the above program is correct and the output obtained is correct, I
> am able go forward with the same program to be implemented in ADSP
> 21061 EZKit Lite.

Ciao,

Peter K.

--
Peter J. Kootsookos

"Na, na na na na na na, na na na na"
- 'Hey Jude', Lennon/McCartney
```
```On 19 Jul 2003 08:27:08 +1000, p.kootsookos@remove.ieee.org (Peter J.
Kootsookos) wrote:

>Hi All,
>
>No comments on what you're doing, but how you're doing it.
>
...

>> %Filter Coefficients
>>     i=1;
>>
>>     for m=0:n2:2*fc,
>>         y(i)=1/(1+((m/fc).^(2*N)));
>>         i=i+1;
>>     end;
>
>Same here:
>
>	y = 1./(1+([0:n2:2*fc].^2*N));
>
>
>Ciao,
>
>Peter J. Kootsookos

I always have this struggle with my love-hate relationship with
matlab.  Being able to do things like you've illustrated make it nice
to work with, but there are so many other things I really dislike
about it.   We're in the middle of transitioning almost all of our
sims to C (after years of me threatening to do so), but I know I'll
miss this sort of thing.

Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org
```
```eric.jacobsen@ieee.org (Eric Jacobsen) writes:

> I always have this struggle with my love-hate relationship with
> matlab.  Being able to do things like you've illustrated make it nice
> to work with, but there are so many other things I really dislike
> about it.   We're in the middle of transitioning almost all of our
> sims to C (after years of me threatening to do so), but I know I'll
> miss this sort of thing.

I had an occassion where I was working with a really good coder.  He
understood how to take C code and vectorise it into matlab with
minimal performance hit.  At one stage, he had some C code to
vectorise and, due to the incredible silly way the C code was written,
his matlab implementation was 3 times faster.

We tweaked the algorithm a little and he re-coded it in C from scratch.

THe final C code ran 9 times faster than the original C code with
slightly better performance.

matlab's [lack of] speed) that they should look at their code first.

Ciao,

Peter K.

--
Peter J. Kootsookos

"Na, na na na na na na, na na na na"
- 'Hey Jude', Lennon/McCartney
```
```On 20 Jul 2003 10:11:44 +1000, p.kootsookos@remove.ieee.org (Peter J.
Kootsookos) wrote:

>eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>
>> I always have this struggle with my love-hate relationship with
>> matlab.  Being able to do things like you've illustrated make it nice
>> to work with, but there are so many other things I really dislike
>> about it.   We're in the middle of transitioning almost all of our
>> sims to C (after years of me threatening to do so), but I know I'll
>> miss this sort of thing.
>
>I had an occassion where I was working with a really good coder.  He
>understood how to take C code and vectorise it into matlab with
>minimal performance hit.  At one stage, he had some C code to
>vectorise and, due to the incredible silly way the C code was written,
>his matlab implementation was 3 times faster.
>
>We tweaked the algorithm a little and he re-coded it in C from scratch.
>
>THe final C code ran 9 times faster than the original C code with
>slightly better performance.
>
>matlab's [lack of] speed) that they should look at their code first.
>
>Ciao,
>
>Peter K.

Absolutely.   Writing fast Matlab requires good coding skills, though,
and an understanding of what makes things fast or inefficient.
Someone who can write fast Matlab code can usually write must faster C
code.   That's a little obvious, I guess, but it's one of the things
we're up against.

We have a pretty large, computationally intensive Matlab suite that
we're in the middle of wringing out.  The coder was complaining it was
taking about seven hours to generate a single output point (on a
1.2GHz P4).   I was given an overview of the code architecture and
then suggested some changes.  I'm told those changes provided an

Matlab can be pretty fast, C can be faster, but either is highly
dependant on the skill of the coder.

Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org
```
```eric.jacobsen@ieee.org (Eric Jacobsen) wrote in message
> On 20 Jul 2003 10:11:44 +1000, p.kootsookos@remove.ieee.org (Peter J.
> Kootsookos) wrote:
>
> >eric.jacobsen@ieee.org (Eric Jacobsen) writes:
> >
> >> I always have this struggle with my love-hate relationship with
> >> matlab.  Being able to do things like you've illustrated make it nice
> >> to work with, but there are so many other things I really dislike
> >> about it.   We're in the middle of transitioning almost all of our
> >> sims to C (after years of me threatening to do so), but I know I'll
> >> miss this sort of thing.
> >
> >I had an occassion where I was working with a really good coder.  He
> >understood how to take C code and vectorise it into matlab with
> >minimal performance hit.  At one stage, he had some C code to
> >vectorise and, due to the incredible silly way the C code was written,
> >his matlab implementation was 3 times faster.
> >
> >We tweaked the algorithm a little and he re-coded it in C from scratch.
> >
> >THe final C code ran 9 times faster than the original C code with
> >slightly better performance.

I don't understand? Do you measure performance in other units than speed?

> >That experience has always made me think (when people complain about
> >matlab's [lack of] speed) that they should look at their code first.
> >
> >Ciao,
> >
> >Peter K.
>
> Absolutely.   Writing fast Matlab requires good coding skills, though,
> and an understanding of what makes things fast or inefficient.
> Someone who can write fast Matlab code can usually write must faster C
> code.   That's a little obvious, I guess, but it's one of the things
> we're up against.
>
> We have a pretty large, computationally intensive Matlab suite that
> we're in the middle of wringing out.  The coder was complaining it was
> taking about seven hours to generate a single output point (on a
> 1.2GHz P4).   I was given an overview of the code architecture and
> then suggested some changes.  I'm told those changes provided an
>
> Matlab can be pretty fast, C can be faster, but either is highly
> dependant on the skill of the coder.

What C is concerned, performance does definately depend on the skill
of the coder. Matters are somewhat more complex with matlab. The problem
is (was) that matlab is based on computation primitives that are (were)
optimized for operations on 1D or 2D arrays. As long as the operation
can be expressed in terms of available primitives that work on arrays
of dimensions not larger than 2, matlab code can be "vectorized" to give
way better performance that code with explicit, naive control loops.

So if the code requires nested "for to do" loops in three or more levels,

C code runs significantly faster than matlab. I had a little loop that
demonstrated the difference, that I posted here a few months ago. The
naive for-to-do code ran some 40 times slower than the "vectorized"
improved in the last releases of matlab (Matlab 6.5 and higher).

There are a few other issues as well, as code interpreters vs compilers,
copying arguments to and from functions vs refernce-by-pointer, but matlab
is, all in all, a quick'n dirty prototyping tool where ease of use (from
a programmer's point of view) has been achieved at the cost of a severe
penalty in run-time perfomance and code "maintainability".

The "lab" in "matlab" is there for a reason.

Rune
```
```eric.jacobsen@ieee.org (Eric Jacobsen) wrote in message
> On 20 Jul 2003 10:11:44 +1000, p.kootsookos@remove.ieee.org (Peter J.
> Kootsookos) wrote:
>
> >eric.jacobsen@ieee.org (Eric Jacobsen) writes:
> >
> >> I always have this struggle with my love-hate relationship with
> >> matlab.  Being able to do things like you've illustrated make it nice
> >> to work with, but there are so many other things I really dislike
> >> about it.   We're in the middle of transitioning almost all of our
> >> sims to C (after years of me threatening to do so), but I know I'll
> >> miss this sort of thing.
> >
> >I had an occassion where I was working with a really good coder.  He
> >understood how to take C code and vectorise it into matlab with
> >minimal performance hit.  At one stage, he had some C code to
> >vectorise and, due to the incredible silly way the C code was written,
> >his matlab implementation was 3 times faster.
> >
> >We tweaked the algorithm a little and he re-coded it in C from scratch.
> >
> >THe final C code ran 9 times faster than the original C code with
> >slightly better performance.

I don't understand? Do you measure performance in other units than speed?

> >That experience has always made me think (when people complain about
> >matlab's [lack of] speed) that they should look at their code first.
> >
> >Ciao,
> >
> >Peter K.
>
> Absolutely.   Writing fast Matlab requires good coding skills, though,
> and an understanding of what makes things fast or inefficient.
> Someone who can write fast Matlab code can usually write must faster C
> code.   That's a little obvious, I guess, but it's one of the things
> we're up against.
>
> We have a pretty large, computationally intensive Matlab suite that
> we're in the middle of wringing out.  The coder was complaining it was
> taking about seven hours to generate a single output point (on a
> 1.2GHz P4).   I was given an overview of the code architecture and
> then suggested some changes.  I'm told those changes provided an
>
> Matlab can be pretty fast, C can be faster, but either is highly
> dependant on the skill of the coder.

What C is concerned, performance does definately depend on the skill
of the coder. Matters are somewhat more complex with matlab. The problem
is (was) that matlab is based on computation primitives that are (were)
optimized for operations on 1D or 2D arrays. As long as the operation
can be expressed in terms of available primitives that work on arrays
of dimensions not larger than 2, matlab code can be "vectorized" to give
way better performance that code with explicit, naive control loops.

So if the code requires nested "for to do" loops in three or more levels,

C code runs significantly faster than matlab. I had a little loop that
demonstrated the difference, that I posted here a few months ago. The
naive for-to-do code ran some 40 times slower than the "vectorized"
improved in the last releases of matlab (Matlab 6.5 and higher).

There are a few other issues as well, as code interpreters vs compilers,
copying arguments to and from functions vs refernce-by-pointer, but matlab
is, all in all, a quick'n dirty prototyping tool where ease of use (from
a programmer's point of view) has been achieved at the cost of a severe
penalty in run-time perfomance and code "maintainability".

The "lab" in "matlab" is there for a reason.

Rune
```
```On 20 Jul 2003 10:11:44 +1000, p.kootsookos@remove.ieee.org (Peter J.
Kootsookos) wrote:

>eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>
>> I always have this struggle with my love-hate relationship with
>> matlab.  Being able to do things like you've illustrated make it nice
>> to work with, but there are so many other things I really dislike
>> about it.   We're in the middle of transitioning almost all of our
>> sims to C (after years of me threatening to do so), but I know I'll
>> miss this sort of thing.
>
>I had an occassion where I was working with a really good coder.  He
>understood how to take C code and vectorise it into matlab with
>minimal performance hit.  At one stage, he had some C code to
>vectorise and, due to the incredible silly way the C code was written,
>his matlab implementation was 3 times faster.
>
>We tweaked the algorithm a little and he re-coded it in C from scratch.
>
>THe final C code ran 9 times faster than the original C code with
>slightly better performance.
>
>matlab's [lack of] speed) that they should look at their code first.
>
>Ciao,
>
>Peter K.

Absolutely.   Writing fast Matlab requires good coding skills, though,
and an understanding of what makes things fast or inefficient.
Someone who can write fast Matlab code can usually write must faster C
code.   That's a little obvious, I guess, but it's one of the things
we're up against.

We have a pretty large, computationally intensive Matlab suite that
we're in the middle of wringing out.  The coder was complaining it was
taking about seven hours to generate a single output point (on a
1.2GHz P4).   I was given an overview of the code architecture and
then suggested some changes.  I'm told those changes provided an

Matlab can be pretty fast, C can be faster, but either is highly
dependant on the skill of the coder.

Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org
```
```eric.jacobsen@ieee.org (Eric Jacobsen) writes:

> I always have this struggle with my love-hate relationship with
> matlab.  Being able to do things like you've illustrated make it nice
> to work with, but there are so many other things I really dislike
> about it.   We're in the middle of transitioning almost all of our
> sims to C (after years of me threatening to do so), but I know I'll
> miss this sort of thing.

I had an occassion where I was working with a really good coder.  He
understood how to take C code and vectorise it into matlab with
minimal performance hit.  At one stage, he had some C code to
vectorise and, due to the incredible silly way the C code was written,
his matlab implementation was 3 times faster.

We tweaked the algorithm a little and he re-coded it in C from scratch.

THe final C code ran 9 times faster than the original C code with
slightly better performance.

matlab's [lack of] speed) that they should look at their code first.

Ciao,

Peter K.

--
Peter J. Kootsookos

"Na, na na na na na na, na na na na"
- 'Hey Jude', Lennon/McCartney
```
```On 19 Jul 2003 08:27:08 +1000, p.kootsookos@remove.ieee.org (Peter J.
Kootsookos) wrote:

>Hi All,
>
>No comments on what you're doing, but how you're doing it.
>
...

>> %Filter Coefficients
>>     i=1;
>>
>>     for m=0:n2:2*fc,
>>         y(i)=1/(1+((m/fc).^(2*N)));
>>         i=i+1;
>>     end;
>
>Same here:
>
>	y = 1./(1+([0:n2:2*fc].^2*N));
>
>
>Ciao,
>
>Peter J. Kootsookos

I always have this struggle with my love-hate relationship with
matlab.  Being able to do things like you've illustrated make it nice
to work with, but there are so many other things I really dislike
about it.   We're in the middle of transitioning almost all of our
sims to C (after years of me threatening to do so), but I know I'll
miss this sort of thing.

Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org
```
```Hi All,

No comments on what you're doing, but how you're doing it.

suma_kin@yahoo.com (Suman) writes:

> hi everybody,
>
> I am working on MAtlab for verification of Butterworth Filter for low
> pass filter, I have written the following program for it,
>      N=20;%Order of Filter
>      fc=200;%Cut-off frequency of filter
>      fs=5000;%Sampling Frequency
>      fin=1000;%Input frequency of pure sine wave
>
>      n1=fs/fin; %No. of samples in sine value
>      n2=fs/fc;
>
>     i=1;
> %Input Coefficients
>     for m=0:2*pi/n1:2*pi,
>        x(i)=sin(m);
>        i=i+1;
>     end;

It's easier (and faster for more complex loops) to write:

x = sin(0:2*pi/n1:2*pi);

> %Filter Coefficients
>     i=1;
>
>     for m=0:n2:2*fc,
>         y(i)=1/(1+((m/fc).^(2*N)));
>         i=i+1;
>     end;

Same here:

y = 1./(1+([0:n2:2*fc].^2*N));

> %Output Coefficients.
>     z=conv(x,y1);
>
> If the above program is correct and the output obtained is correct, I
> am able go forward with the same program to be implemented in ADSP
> 21061 EZKit Lite.

Ciao,

Peter K.

--
Peter J. Kootsookos

"Na, na na na na na na, na na na na"
- 'Hey Jude', Lennon/McCartney
```
```On Fri, 18 Jul 2003 11:31:31 -0400, "Clay S. Turner"
<physicsNOOOOSPPPPAMMMM@bellsouth.net> wrote:

>Hello Suman,
>
>While I'm not a Matlab guy, it appears (If I read your program correctly)
>that you are convolving your data with an FIR filter whose tap values are
>the mangitude of a Butterworth filter. If this is the case, it will fail for
>several reasons. One: the Butterworth filter is an IIR design. Two: the
>Butterworth filter has a phase response different from what you have here.
>Third: the magnitude response for a Butterworth needs a square root which is
>left out. And of course the taps in an FIR filter are the impulse response
>and not the frequency response.
>
>Clay

Actually, you can get a very good Butterworth response with a FIR
design.  See

http://www.dspguru.com/comp.dsp/tricks/dsn/nlp_fir.htm

for a brief description how.

>"Suman" <suma_kin@yahoo.com> wrote in message
>> hi everybody,
>>
>> I am working on MAtlab for verification of Butterworth Filter for low
>> pass filter, I have written the following program for it,
>>      N=20;%Order of Filter
>>      fc=200;%Cut-off frequency of filter
>>      fs=5000;%Sampling Frequency
>>      fin=1000;%Input frequency of pure sine wave
>>
>>      n1=fs/fin; %No. of samples in sine value
>>      n2=fs/fc;
>>
>>     i=1;
>> %Input Coefficients
>>     for m=0:2*pi/n1:2*pi,
>>        x(i)=sin(m);
>>        i=i+1;
>>     end;
>> %Filter Coefficients
>>     i=1;
>>
>>     for m=0:n2:2*fc,
>>         y(i)=1/(1+((m/fc).^(2*N)));
>>         i=i+1;
>>     end;
>> %Output Coefficients.
>>     z=conv(x,y1);
>>
>> If the above program is correct and the output obtained is correct, I
>> am able go forward with the same program to be implemented in ADSP
>> 21061 EZKit Lite.
>
>
>

Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org
```
```Hello Suman,

While I'm not a Matlab guy, it appears (If I read your program correctly)
that you are convolving your data with an FIR filter whose tap values are
the mangitude of a Butterworth filter. If this is the case, it will fail for
several reasons. One: the Butterworth filter is an IIR design. Two: the
Butterworth filter has a phase response different from what you have here.
Third: the magnitude response for a Butterworth needs a square root which is
left out. And of course the taps in an FIR filter are the impulse response
and not the frequency response.

Clay

"Suman" <suma_kin@yahoo.com> wrote in message
> hi everybody,
>
> I am working on MAtlab for verification of Butterworth Filter for low
> pass filter, I have written the following program for it,
>      N=20;%Order of Filter
>      fc=200;%Cut-off frequency of filter
>      fs=5000;%Sampling Frequency
>      fin=1000;%Input frequency of pure sine wave
>
>      n1=fs/fin; %No. of samples in sine value
>      n2=fs/fc;
>
>     i=1;
> %Input Coefficients
>     for m=0:2*pi/n1:2*pi,
>        x(i)=sin(m);
>        i=i+1;
>     end;
> %Filter Coefficients
>     i=1;
>
>     for m=0:n2:2*fc,
>         y(i)=1/(1+((m/fc).^(2*N)));
>         i=i+1;
>     end;
> %Output Coefficients.
>     z=conv(x,y1);
>
> If the above program is correct and the output obtained is correct, I
> am able go forward with the same program to be implemented in ADSP
> 21061 EZKit Lite.

```
```hi everybody,

I am working on MAtlab for verification of Butterworth Filter for low
pass filter, I have written the following program for it,
N=20;%Order of Filter
fc=200;%Cut-off frequency of filter
fs=5000;%Sampling Frequency
fin=1000;%Input frequency of pure sine wave

n1=fs/fin; %No. of samples in sine value
n2=fs/fc;

i=1;
%Input Coefficients
for m=0:2*pi/n1:2*pi,
x(i)=sin(m);
i=i+1;
end;
%Filter Coefficients
i=1;

for m=0:n2:2*fc,
y(i)=1/(1+((m/fc).^(2*N)));
i=i+1;
end;
%Output Coefficients.
z=conv(x,y1);

If the above program is correct and the output obtained is correct, I
am able go forward with the same program to be implemented in ADSP
21061 EZKit Lite.