How to use Jake's Remez Exchange code to design a differenciator?

Started by chenjc March 3, 2007
Guys,

I have a little problem to use his code to design a differentiator.
To use the Remez in Matlab, we specify the gain expected at the band
edge.

But in Jake's code, only one desired value is allowed in each band. What I
should give for differentiator? I tied to give the slope. But id gave a
totally different result from the matlab one. 

Does anyone know how to use it or is there any example to use his code? 

Thanks for your help.
Jichao



On 3 Mrz., 22:20, "chenjc" <jichao.c...@gmail.com> wrote:
> Guys, > > I have a little problem to use his code to design a differentiator. > To use the Remez in Matlab, we specify the gain expected at the band > edge. > > But in Jake's code, only one desired value is allowed in each band. What I > should give for differentiator?
Ask Jake.
> I tied to give the slope. But id gave a > totally different result from the matlab one. > > Does anyone know how to use it or is there any example to use his code
Doesn't this strike anybody else as odd how we are increasedly getting exactly the same question asked several times??
On 3 Mar, 22:20, "chenjc" <jichao.c...@gmail.com> wrote:
> Guys, > > I have a little problem to use his code to design a differentiator. > To use the Remez in Matlab, we specify the gain expected at the band > edge. > > But in Jake's code, only one desired value is allowed in each band. What I > should give for differentiator? I tied to give the slope. But id gave a > totally different result from the matlab one.
What makes you think the code can be used to design differentiators? Have you looked through the theory behind FIR differentiators? Do you know their characteristics? Do you recognize their peoperties in this code you have found? Remember, there is a very real possibility that the freeware code was never designed to deal with anything but plain vanilla FIR filters.
> Does anyone know how to use it
The author does -- or ought to. Did you find an email address along with the code? Any disclaimers about usability or support? Rune
On Mar 4, 2:46 am, "Rune Allnor" <wrote:
> What makes you think the code can be used to design differentiators? > Have you looked through the theory behind FIR differentiators? Do you > know their characteristics? Do you recognize their peoperties in this > code you have found? > > Remember, there is a very real possibility that the freeware code was > never designed to deal with anything but plain vanilla FIR filters.
That's fine. But Jake has written his code with pointers to Discrete- time Signal Processing by Oppenheim and Schafer. Also, in his remez.h header, he has defined three numbers to pass to functions for band- pass, differentiator and Hilbert transformers. He also scales the weights for doing the equiripple design by 1 / frequency for differentiators, which is also from the theory. However, this despite, it fails to work.
> > Does anyone know how to use it > > The author does -- or ought to. Did you find an email address > along with the code? Any disclaimers about usability or support?
Fair enough, agreed. :-) Kumar
"Kumar Appaiah" <kumar.appaiah@gmail.com> wrote in message 
news:1172971538.605956.152490@j27g2000cwj.googlegroups.com...
> On Mar 4, 2:46 am, "Rune Allnor" <wrote: >> What makes you think the code can be used to design differentiators? >> Have you looked through the theory behind FIR differentiators? Do you >> know their characteristics? Do you recognize their peoperties in this >> code you have found? >> >> Remember, there is a very real possibility that the freeware code was >> never designed to deal with anything but plain vanilla FIR filters. > > That's fine. But Jake has written his code with pointers to Discrete- > time Signal Processing by Oppenheim and Schafer. Also, in his remez.h > header, he has defined three numbers to pass to functions for band- > pass, differentiator and Hilbert transformers. He also scales the > weights for doing the equiripple design by 1 / frequency for > differentiators, which is also from the theory. However, this despite, > it fails to work. > >> > Does anyone know how to use it >> >> The author does -- or ought to. Did you find an email address >> along with the code? Any disclaimers about usability or support? > > Fair enough, agreed. :-) > > Kumar
In the Parks-McClellan Fortran source code, an input example is given for a differentiator as follows: 32,2,1,0,0 0,0.5 1.0 1.0 The first line says: "Length 32", Type 2 = Differentiator, "1 band",0=no card punch,0=grid density 16. Band edges 0 and 0.5 (which is fs/2 and the maximum frequency dealt with) 1.0 = Desired slope (when a differentiator) 1.0 = Weight in the band (1.0/f when a differentiator) In Jake Janovetz' C code, variables are passed as follows: void remez(double h[], int numtaps,int numband, double bands[], double des[], double weight[],int type); An educated guess as it's been a *long* time since I'd read this code: h is the filter coefficients returned, numtaps is the length of the filter, numband is the number of bands, bands is the specification of band edge frequencies, des is the desired response in each band, weight is the weight for each band, type is the type of filter. This is very similar to the Parks-McClellan code I'm sure you'll see. Just the code for getting the parameters in the program is different. So for the same differentiator, I think it must be numtaps=32 numband=1 bands= 0 .05 des=1 weight=1 meaning 1/f I would guess type=2 If that doesn't work then you must be using a different convention for program input. In Matlab, according to web pages on the subject: http://www.utexas.edu/its/rc/answers/matlab/faq6.html#6.1.3. b=remez(11,[0 1],[0 10000*pi],'differentiator'); means a length 12 filter (order 11) with fs=10000 My version of the Parks-McClellan program takes inputs 32 %the length 2 %the type=differentiator 1 %number of bands 0,0.5 %band edges 1 %slope (for a differentiator) 1 %weight It seems to work fine. No surprise! Fred
On 4 Mar, 02:25, "Kumar Appaiah" <kumar.appa...@gmail.com> wrote:
> On Mar 4, 2:46 am, "Rune Allnor" <wrote: > > > What makes you think the code can be used to design differentiators? > > Have you looked through the theory behind FIR differentiators? Do you > > know their characteristics? Do you recognize their peoperties in this > > code you have found? > > > Remember, there is a very real possibility that the freeware code was > > never designed to deal with anything but plain vanilla FIR filters. > > That's fine. But Jake has written his code with pointers to Discrete- > time Signal Processing by Oppenheim and Schafer.
So? It would make the code easier to read for someone who does not quite exactly how the code achieves what it does, but that's no guarantee for it doing everything one wants it to do. Rune
On Mar 4, 12:56 pm, "Rune Allnor" wrote:
> > That's fine. But Jake has written his code with pointers to Discrete- > > time Signal Processing by Oppenheim and Schafer. > > So? It would make the code easier to read for someone who > does not quite exactly how the code achieves what it does, > but that's no guarantee for it doing everything one wants it to do.
I do not dispute this. I wanted to see an implementation which did work, and had some documentation. I did not really expect it to do everything, but since it was indicated that it could do differentiators and Hilbert Transformers, just wanted to know if someone else had managed to figure out how to get it. Thanks. Kumar
"Rune Allnor" <allnor@tele.ntnu.no> wrote in message 
news:1172995018.479967.302460@v33g2000cwv.googlegroups.com...
> On 4 Mar, 02:25, "Kumar Appaiah" <kumar.appa...@gmail.com> wrote: >> On Mar 4, 2:46 am, "Rune Allnor" <wrote: >> >> > What makes you think the code can be used to design differentiators? >> > Have you looked through the theory behind FIR differentiators? Do you >> > know their characteristics? Do you recognize their peoperties in this >> > code you have found? >> >> > Remember, there is a very real possibility that the freeware code was >> > never designed to deal with anything but plain vanilla FIR filters. >> >> That's fine. But Jake has written his code with pointers to Discrete- >> time Signal Processing by Oppenheim and Schafer. > > So? It would make the code easier to read for someone who > does not quite exactly how the code achieves what it does, > but that's no guarantee for it doing everything one wants it to do. > > Rune
Rune, I think the OP meant that the code provides text reference comments to the literature - that's all. It includes the ability to design differentiators just like P-M does. It appears the issue here is that the OP doesn't know how to structure the input parameters: In the Fortran versions that started with punch cards it's a command line interface that's similar. P-M is like that. My programs are like that. They are standalone programs that ask for input and give output. Jake Janovetz' C coded version turns the same approach but sets it up as a callable function. So, one has to know how to embed that function/code into a program that will do the job. This isn't a filter design problem, it's an implementation problem as I understand it. About the only thing one might say is that a differentiator specification should give an even length. My other post in this thread provides interfaces for 3 popular programs. Fred
On 4 Mar, 19:15, "Fred Marshall" <fmarshallx@remove_the_x.acm.org>
wrote:
> "Rune Allnor" <all...@tele.ntnu.no> wrote in message > > news:1172995018.479967.302460@v33g2000cwv.googlegroups.com... > > > > > > > On 4 Mar, 02:25, "Kumar Appaiah" <kumar.appa...@gmail.com> wrote: > >> On Mar 4, 2:46 am, "Rune Allnor" <wrote: > > >> > What makes you think the code can be used to design differentiators? > >> > Have you looked through the theory behind FIR differentiators? Do you > >> > know their characteristics? Do you recognize their peoperties in this > >> > code you have found? > > >> > Remember, there is a very real possibility that the freeware code was > >> > never designed to deal with anything but plain vanilla FIR filters. > > >> That's fine. But Jake has written his code with pointers to Discrete- > >> time Signal Processing by Oppenheim and Schafer. > > > So? It would make the code easier to read for someone who > > does not quite exactly how the code achieves what it does, > > but that's no guarantee for it doing everything one wants it to do. > > > Rune > > Rune, > > I think the OP meant that the code provides text reference comments to the > literature - that's all. It includes the ability to design differentiators > just like P-M does. It appears the issue here is that the OP doesn't know > how to structure the input parameters: > In the Fortran versions that started with punch cards it's a command line > interface that's similar. P-M is like that. My programs are like that.
I try not to do things like that. While I perfer to use command-line versions during development and debugging, I tend to structure the programs as interfaces and useful procedures (well, objects, but that's not important for the purposes of this discussion). By doing things like that, debugging ecomes easy and it doesn't take a lot of work to link the files under matlab as a MEX file.
> They are standalone programs that ask for input and give output. > Jake Janovetz' C coded version turns the same approach but sets it up as a > callable function.
It's a long time since I stopped looking at other people's code unless it was really necessary. I remember an early version of an acoustic model (SAFARI) where the visualization package (the package was developed long before matlab became standard) was hard-coded into the model. So if you wanted to change the data to be plotted, you had to run the whole model from scratch, usually taking hours. That was fixed to the next version (OASES), where the model and visualization were two different prgrams, but it is representative for what I have learned to expect in shareware code.
> So, one has to know how to embed that function/code into > a program that will do the job.
If the author knows what he is doing, and how to document his work, that shouldn't be too difficult.
> This isn't a filter design problem, it's an implementation problem as I > understand it.
Agreed. Which is why I didn't see the significance of this code referring to O&S.
> About the only thing one might say is that a differentiator specification > should give an even length.
I assume we are talking about FIR differentiators? The spec is |H(w)| = w right? So we need a zero at w=0. You can achieve that for both even and odd FIR lengths: An even-length FIR with antisymmetric coefficients will get there, and so will an odd-length FIR with antisymmetric coefficients. Of course, I haven't considered the phase to be important, which probably is an obvious give-away for the fact that I haven't actually designed a FIR diferentiator from scratch... Rune
"Rune Allnor" <allnor@tele.ntnu.no> wrote in message 
news:1173033331.526579.83520@p10g2000cwp.googlegroups.com...
> On 4 Mar, 19:15, "Fred Marshall" <fmarshallx@remove_the_x.acm.org> > wrote: >> "Rune Allnor" <all...@tele.ntnu.no> wrote in message >> >> news:1172995018.479967.302460@v33g2000cwv.googlegroups.com... >> >> >> >> >> >> > On 4 Mar, 02:25, "Kumar Appaiah" <kumar.appa...@gmail.com> wrote: >> >> On Mar 4, 2:46 am, "Rune Allnor" <wrote: >> >> >> > What makes you think the code can be used to design differentiators? >> >> > Have you looked through the theory behind FIR differentiators? Do >> >> > you >> >> > know their characteristics? Do you recognize their peoperties in >> >> > this >> >> > code you have found? >> >> >> > Remember, there is a very real possibility that the freeware code >> >> > was >> >> > never designed to deal with anything but plain vanilla FIR filters. >> >> >> That's fine. But Jake has written his code with pointers to Discrete- >> >> time Signal Processing by Oppenheim and Schafer. >> >> > So? It would make the code easier to read for someone who >> > does not quite exactly how the code achieves what it does, >> > but that's no guarantee for it doing everything one wants it to do. >> >> > Rune >> >> Rune, >> >> I think the OP meant that the code provides text reference comments to >> the >> literature - that's all. It includes the ability to design >> differentiators >> just like P-M does. It appears the issue here is that the OP doesn't >> know >> how to structure the input parameters: >> In the Fortran versions that started with punch cards it's a command line >> interface that's similar. P-M is like that. My programs are like that. > > I try not to do things like that. While I perfer to use command-line > versions during development and debugging, I tend to structure the > programs as interfaces and useful procedures (well, objects, but > that's > not important for the purposes of this discussion). By doing things > like > that, debugging ecomes easy and it doesn't take a lot of work to link > the > files under matlab as a MEX file. > >> They are standalone programs that ask for input and give output. >> Jake Janovetz' C coded version turns the same approach but sets it up as >> a >> callable function. > > It's a long time since I stopped looking at other people's code > unless it was really necessary. I remember an early version > of an acoustic model (SAFARI) where the visualization > package (the package was developed long before matlab > became standard) was hard-coded into the model. So if > you wanted to change the data to be plotted, you had to > run the whole model from scratch, usually taking hours. > That was fixed to the next version (OASES), where the > model and visualization were two different prgrams, but > it is representative for what I have learned to expect in > shareware code. > >> So, one has to know how to embed that function/code into >> a program that will do the job. > > If the author knows what he is doing, and how to > document his work, that shouldn't be too difficult. > >> This isn't a filter design problem, it's an implementation problem as I >> understand it. > > Agreed. Which is why I didn't see the significance of this > code referring to O&S. > >> About the only thing one might say is that a differentiator specification >> should give an even length. > > I assume we are talking about FIR differentiators? The spec is > > |H(w)| = w > > right? So we need a zero at w=0. You can achieve that for both > even and odd FIR lengths: An even-length FIR with antisymmetric > coefficients will get there, and so will an odd-length FIR with > antisymmetric coefficients. > > Of course, I haven't considered the phase to be important, which > probably is an obvious give-away for the fact that I haven't actually > designed a FIR diferentiator from scratch... > > Rune
For an odd length the result is terrible. It appears there's a sinusoidal component in the magnitude response at the highest possible quefrency - suggesting a doublet in the unit sample response at the ends. And, indeed, that's what you get! In fact, the values for the unit sample response are pretty terrible for length 33 while, for length 32, the unit sample response looks like [.......1 -1 .....] where the .... parts are rather small "adjustments" it appears. I'd have to ponder further why this is. It suggests that getting the desired response is indeed difficult for an odd length. There should be some doh! factoid to tell us why. I can't think of it right now. It occurs to me that the OP may be having this problem: I notice that the output of the P-M program provides only half the unit sample response and the upper half of the coefficients are labeled "-H(xx)" Note the minus sign! I missed it the first time! So the sequence not only has to be reversed but it has to have its sign changed to make up the complete set of coefficients. Fred