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.
please help me regarding this.
ButterWOrth filter using matlab
Started by ●July 18, 2003
Reply by ●July 18, 20032003-07-18
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 news:aac84c5a.0307180207.776cea7c@posting.google.com...> 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. > please help me regarding this.
Reply by ●July 18, 20032003-07-18
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. > >ClayActually, 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 >news:aac84c5a.0307180207.776cea7c@posting.google.com... >> 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. >> please help me regarding this. > > >Eric Jacobsen Minister of Algorithms, Intel Corp. My opinions may not be Intel's opinions. http://www.ericjacobsen.org
Reply by ●July 18, 20032003-07-18
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. > please help me regarding this.Ciao, Peter K. -- Peter J. Kootsookos "Na, na na na na na na, na na na na" - 'Hey Jude', Lennon/McCartney
Reply by ●July 19, 20032003-07-19
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. KootsookosI 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
Reply by ●July 19, 20032003-07-19
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. 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. -- Peter J. Kootsookos "Na, na na na na na na, na na na na" - 'Hey Jude', Lennon/McCartney
Reply by ●July 26, 20032003-07-26
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. > >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 improvement of about 10x! 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
Reply by ●July 27, 20032003-07-27
eric.jacobsen@ieee.org (Eric Jacobsen) wrote in message news:<3f22b703.46220328@news.earthlink.net>...> 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 > improvement of about 10x! > > 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" version. Somebody made me aware that the performance had been significantly 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
