# fir1 question on symmetry

16 messages
Open this post in threaded view
|

## fir1 question on symmetry

 Hi, Regarding the fir1 function and the "blackmanharris" window; If I specify an even number of coefficients (n) it produces a symmetric filter with an odd number of coefficients (n+1). If I specify an odd number of coefficients it produces a non symmetric filter with an even number of coefficients. octave:39> version ans = 3.0.5 octave:40> b=fir1(8, 0.5, "blackmanharris") b =   Columns 1 through 8:    -7.1851e-08  -2.8280e-03   2.6042e-04   2.7158e-01   6.1193e-01   2.7158e-01   2.6042e-04  -2.8280e-03   Column 9:    -7.1851e-08 octave:41> b=fir1(7, 0.5, "blackmanharris") b =    -3.8206e-04  -5.2516e-04   2.6785e-02   3.8140e-01   6.1393e-01   1.2791e-01  -1.5875e-02  -3.8206e-04 octave:42> Is there some trick to producing a symmetric "blackmanharris" windowed filter with an even number of coefficients? Regards, James. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Octave-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/octave-dev
Open this post in threaded view
|

## Re: fir1 question on symmetry

 On 08/05/12 09:39, James Steward wrote: > Hi, > > Regarding the fir1 function and the "blackmanharris" window; > > If I specify an even number of coefficients (n) it produces a symmetric > filter with an odd number of coefficients (n+1). > > If I specify an odd number of coefficients it produces a non symmetric > filter with an even number of coefficients. > > octave:39>  version > ans = 3.0.5 > octave:40>  b=fir1(8, 0.5, "blackmanharris") > b = > >    Columns 1 through 8: > >     -7.1851e-08  -2.8280e-03   2.6042e-04   2.7158e-01   6.1193e-01 > 2.7158e-01   2.6042e-04  -2.8280e-03 > >    Column 9: > >     -7.1851e-08 > > octave:41>  b=fir1(7, 0.5, "blackmanharris") > b = > >     -3.8206e-04  -5.2516e-04   2.6785e-02   3.8140e-01   6.1393e-01 > 1.2791e-01  -1.5875e-02  -3.8206e-04 > > octave:42> > > Is there some trick to producing a symmetric "blackmanharris" windowed > filter with an even number of coefficients? >     In reply to myself, I looked at the wikipedia page [1] that describes the Blackman-Harris filter, and wrote my own blackmanharris.m function from that.  It seems to work just fine, though with no parameter sensibility checking. Then out of curiosity I checked my installed signal library function [2] and found that it is certainly different. [1] http://en.wikipedia.org/wiki/Window_function#Blackman.E2.80.93Harris_window[2] /usr/share/octave/packages/signal-1.0.10/blackmanharris.m Regards, James. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Octave-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/octave-dev
Open this post in threaded view
|

## Re: fir1 question on symmetry

 On 05/07/2012 07:39 PM, James Steward wrote: > On 08/05/12 09:39, James Steward wrote: >> Hi, >> >> Regarding the fir1 function and the "blackmanharris" window; >> >> If I specify an even number of coefficients (n) it produces a symmetric >> filter with an odd number of coefficients (n+1). >> >> If I specify an odd number of coefficients it produces a non symmetric >> filter with an even number of coefficients. N is the order, not the number of coefficients.  E.g., second order equation would have three coefficients. >> octave:39>   version >> ans = 3.0.5 >> octave:40>   b=fir1(8, 0.5, "blackmanharris") >> b = >> >>     Columns 1 through 8: >> >>      -7.1851e-08  -2.8280e-03   2.6042e-04   2.7158e-01   6.1193e-01 >> 2.7158e-01   2.6042e-04  -2.8280e-03 >> >>     Column 9: >> >>      -7.1851e-08 >> >> octave:41>   b=fir1(7, 0.5, "blackmanharris") >> b = >> >>      -3.8206e-04  -5.2516e-04   2.6785e-02   3.8140e-01   6.1393e-01 >> 1.2791e-01  -1.5875e-02  -3.8206e-04 >> >> octave:42> >> >> Is there some trick to producing a symmetric "blackmanharris" windowed >> filter with an even number of coefficients? >> > > In reply to myself, I looked at the wikipedia page [1] that describes > the Blackman-Harris filter, and wrote my own blackmanharris.m function > from that.  It seems to work just fine, though with no parameter > sensibility checking. > > Then out of curiosity I checked my installed signal library function [2] > and found that it is certainly different. > > [1] > http://en.wikipedia.org/wiki/Window_function#Blackman.E2.80.93Harris_window> [2] /usr/share/octave/packages/signal-1.0.10/blackmanharris.m Good catch James.  The first thing I recognize is that the formula doesn't appear to match what is listed in the Wikipedia reference.  In the file [2] is the code          a0 = 0.35875;          a1 = 0.48829;          a2 = 0.14128;          a3 = 0.01168;          n = -ceil(N/2):N/2;          w = a0 + a1.*cos(2.*pi.*n./N) + a2.*cos(4.*pi.*n./N) + a3.*cos(6.*pi.*n./N); But according to [1], it should be "- a1" and "- a3".  HOWEVER, I made that change and ended up with a window where the tail is weighted more than the center, so I think that Wikipedia might have the wrong formula.   Agreed? Also, this formula inside of blackmanharris.m: n = -ceil(N/2):N/2; does not produce the desired result for N odd. octave:33> N=7 N =  7 octave:34> n = -ceil(N/2):N/2 n =    -4  -3  -2  -1   0   1   2   3 Instead of defining 'n' the way the code does, it might be better to use the description from the Wiki page that says "w(n) = w_0(n - (N-1)/2)", this N not being the same as the N in the lines above.  Note that blackmanharris.m uses an input L which is the length of window and N = L - 1. I think the definition of n inside blackmanharris.m should be:          n = (0:N) - N/2; Does that produce the result you are expecting James? Dan > > Regards, > James. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/> _______________________________________________ > Octave-dev mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/octave-dev> -- Dan Sebald email: daniel(DOT)sebald(AT)ieee(DOT)org URL: http://www(DOT)dansebald(DOT)com------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Octave-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/octave-dev
Open this post in threaded view
|

## Re: fir1 question on symmetry

 On Mon, May 07, 2012 at 08:54:16PM -0500, Daniel J Sebald wrote: > On 05/07/2012 07:39 PM, James Steward wrote: > > On 08/05/12 09:39, James Steward wrote: > >> Hi, > >> > >> Regarding the fir1 function and the "blackmanharris" window; > >> > >> If I specify an even number of coefficients (n) it produces a symmetric > >> filter with an odd number of coefficients (n+1). > >> > >> If I specify an odd number of coefficients it produces a non symmetric > >> filter with an even number of coefficients. > > N is the order, not the number of coefficients.  E.g., second order > equation would have three coefficients. > > > >> octave:39>   version > >> ans = 3.0.5 > >> octave:40>   b=fir1(8, 0.5, "blackmanharris") > >> b = > >> > >>     Columns 1 through 8: > >> > >>      -7.1851e-08  -2.8280e-03   2.6042e-04   2.7158e-01   6.1193e-01 > >> 2.7158e-01   2.6042e-04  -2.8280e-03 > >> > >>     Column 9: > >> > >>      -7.1851e-08 > >> > >> octave:41>   b=fir1(7, 0.5, "blackmanharris") > >> b = > >> > >>      -3.8206e-04  -5.2516e-04   2.6785e-02   3.8140e-01   6.1393e-01 > >> 1.2791e-01  -1.5875e-02  -3.8206e-04 > >> > >> octave:42> > >> > >> Is there some trick to producing a symmetric "blackmanharris" windowed > >> filter with an even number of coefficients? The answer to this is yes, you can define your own window function and pass in the window as a vector to either fir1 or fir2 rather than a string.  This way you can define the window any way you like.  And as Dan noted, the length of the window you create must be 1 more than the filter order. > > In reply to myself, I looked at the wikipedia page [1] that describes > > the Blackman-Harris filter, and wrote my own blackmanharris.m function > > from that.  It seems to work just fine, though with no parameter > > sensibility checking. > > > > Then out of curiosity I checked my installed signal library function [2] > > and found that it is certainly different. > > > > [1] > > http://en.wikipedia.org/wiki/Window_function#Blackman.E2.80.93Harris_window> > [2] /usr/share/octave/packages/signal-1.0.10/blackmanharris.m > > Good catch James.  The first thing I recognize is that the formula > doesn't appear to match what is listed in the Wikipedia reference.  In > the file [2] is the code > >          a0 = 0.35875; >          a1 = 0.48829; >          a2 = 0.14128; >          a3 = 0.01168; >          n = -ceil(N/2):N/2; >          w = a0 + a1.*cos(2.*pi.*n./N) + a2.*cos(4.*pi.*n./N) + > a3.*cos(6.*pi.*n./N); > > But according to [1], it should be "- a1" and "- a3".  HOWEVER, I made > that change and ended up with a window where the tail is weighted more > than the center, so I think that Wikipedia might have the wrong formula. >   Agreed? The formula in [1] is correct, it's just that the indexing and the signs on the terms need to agree.  If your indexing is from -N/2 to +N/2, the a1 and a3 terms are positive.  If your indexing is from 0 to N, the a1 and a3 terms are negative, which is what [1] shows. > Also, this formula inside of blackmanharris.m: > > n = -ceil(N/2):N/2; > > does not produce the desired result for N odd. > > octave:33> N=7 > N =  7 > octave:34> n = -ceil(N/2):N/2 > n = > >    -4  -3  -2  -1   0   1   2   3 > > Instead of defining 'n' the way the code does, it might be better to use > the description from the Wiki page that says "w(n) = w_0(n - (N-1)/2)", > this N not being the same as the N in the lines above.  Note that > blackmanharris.m uses an input L which is the length of window and N = L > - 1. > > I think the definition of n inside blackmanharris.m should be: > >          n = (0:N) - N/2; > > Does that produce the result you are expecting James? But actually both the current and this behavior do not match ML's blackmanharris function, at least in the version I have at my disposal. Can anyone verify? I just ran it with a couple different lengths and it always returns an asymmetric window, whether the length is even or odd.  Can't say whether this is intentional, other window functions seem to be symmetric. -- mike ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Octave-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/octave-dev
Open this post in threaded view
|

## Re: fir1 question on symmetry

 In reply to this post by Daniel Sebald On 08/05/12 11:54, Daniel J Sebald wrote: On 05/07/2012 07:39 PM, James Steward wrote: On 08/05/12 09:39, James Steward wrote: Hi, Regarding the fir1 function and the "blackmanharris" window; If I specify an even number of coefficients (n) it produces a symmetric filter with an odd number of coefficients (n+1). If I specify an odd number of coefficients it produces a non symmetric filter with an even number of coefficients. N is the order, not the number of coefficients.  E.g., second order equation would have three coefficients. That is evident.  It is the symmetry of the filter that is in question, which seems to be affected by the number of coefficients being odd or even. octave:39>   version ans = 3.0.5 octave:40>   b=fir1(8, 0.5, "blackmanharris") b =     Columns 1 through 8:      -7.1851e-08  -2.8280e-03   2.6042e-04   2.7158e-01   6.1193e-01 2.7158e-01   2.6042e-04  -2.8280e-03     Column 9:      -7.1851e-08 octave:41>   b=fir1(7, 0.5, "blackmanharris") b =      -3.8206e-04  -5.2516e-04   2.6785e-02   3.8140e-01   6.1393e-01 1.2791e-01  -1.5875e-02  -3.8206e-04 octave:42> Is there some trick to producing a symmetric "blackmanharris" windowed filter with an even number of coefficients? In reply to myself, I looked at the wikipedia page [1] that describes the Blackman-Harris filter, and wrote my own blackmanharris.m function from that.  It seems to work just fine, though with no parameter sensibility checking. Then out of curiosity I checked my installed signal library function [2] and found that it is certainly different. [1] http://en.wikipedia.org/wiki/Window_function#Blackman.E2.80.93Harris_window [2] /usr/share/octave/packages/signal-1.0.10/blackmanharris.m Good catch James.  The first thing I recognize is that the formula doesn't appear to match what is listed in the Wikipedia reference.  In the file [2] is the code         a0 = 0.35875;         a1 = 0.48829;         a2 = 0.14128;         a3 = 0.01168;         n = -ceil(N/2):N/2;         w = a0 + a1.*cos(2.*pi.*n./N) + a2.*cos(4.*pi.*n./N) + a3.*cos(6.*pi.*n./N); But according to [1], it should be "- a1" and "- a3".  HOWEVER, I made that change and ended up with a window where the tail is weighted more than the center, so I think that Wikipedia might have the wrong formula.  Agreed? It worked for me, but the definition of n I used was also different. Also, this formula inside of blackmanharris.m: n = -ceil(N/2):N/2; does not produce the desired result for N odd. Correct. octave:33> N=7 N =  7 octave:34> n = -ceil(N/2):N/2 n =   -4  -3  -2  -1   0   1   2   3 Instead of defining 'n' the way the code does, it might be better to use the description from the Wiki page that says "w(n) = w_0(n - (N-1)/2)", this N not being the same as the N in the lines above.  Note that blackmanharris.m uses an input L which is the length of window and N = L - 1. The definition of "n" in the wiki page says "n is an integer, with values 0 ≤ n ≤ N-1." I think the definition of n inside blackmanharris.m should be:         n = (0:N) - N/2; Does that produce the result you are expecting James? I haven't tested this inside the signal toolbox blackmanharris.m file, but it yields non integer values of "n" for L = even numbers, N being then odd, and N/2 resulting in a non integer value. My version of blackmanharris.m, that I simply overloaded the system default with, looks like this; function w = blackmanharris (N)     w = 1;     a0 = 0.35875;     a1 = 0.48829;     a2 = 0.14128;     a3 = 0.01168;     for n=0:N-1         w(n+1) = a0 - a1 * cos(2*pi()*n/(N-1)) + a2 * cos(4*pi()*n/(N-1)) - a3 * cos(6*pi()*n/(N-1));     endfor endfunction; While probably not beautifully efficient, it works.  I.e. appears to be correct. Regards, James. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Octave-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/octave-dev
Open this post in threaded view
|

## Re: fir1 question on symmetry

 On 05/07/2012 09:29 PM, James Steward wrote: > On 08/05/12 11:54, Daniel J Sebald wrote: >> On 05/07/2012 07:39 PM, James Steward wrote: >>> On 08/05/12 09:39, James Steward wrote: >>>> Hi, >>>> >>>> Regarding the fir1 function and the "blackmanharris" window; >>>> >>>> If I specify an even number of coefficients (n) it produces a symmetric >>>> filter with an odd number of coefficients (n+1). >>>> >>>> If I specify an odd number of coefficients it produces a non symmetric >>>> filter with an even number of coefficients. >> >> N is the order, not the number of coefficients. E.g., second order >> equation would have three coefficients. > > That is evident. It is the symmetry of the filter that is in question, > which seems to be affected by the number of coefficients being odd or even. > >>>> octave:39> version >>>> ans = 3.0.5 >>>> octave:40> b=fir1(8, 0.5, "blackmanharris") >>>> b = >>>> >>>> Columns 1 through 8: >>>> >>>> -7.1851e-08 -2.8280e-03 2.6042e-04 2.7158e-01 6.1193e-01 >>>> 2.7158e-01 2.6042e-04 -2.8280e-03 >>>> >>>> Column 9: >>>> >>>> -7.1851e-08 >>>> >>>> octave:41> b=fir1(7, 0.5, "blackmanharris") >>>> b = >>>> >>>> -3.8206e-04 -5.2516e-04 2.6785e-02 3.8140e-01 6.1393e-01 >>>> 1.2791e-01 -1.5875e-02 -3.8206e-04 >>>> >>>> octave:42> >>>> >>>> Is there some trick to producing a symmetric "blackmanharris" windowed >>>> filter with an even number of coefficients? >>>> >>> >>> In reply to myself, I looked at the wikipedia page [1] that describes >>> the Blackman-Harris filter, and wrote my own blackmanharris.m function >>> from that. It seems to work just fine, though with no parameter >>> sensibility checking. >>> >>> Then out of curiosity I checked my installed signal library function [2] >>> and found that it is certainly different. >>> >>> [1] >>> http://en.wikipedia.org/wiki/Window_function#Blackman.E2.80.93Harris_window>>> >>> [2] /usr/share/octave/packages/signal-1.0.10/blackmanharris.m >> >> Good catch James. The first thing I recognize is that the formula >> doesn't appear to match what is listed in the Wikipedia reference. In >> the file [2] is the code >> >> a0 = 0.35875; >> a1 = 0.48829; >> a2 = 0.14128; >> a3 = 0.01168; >> n = -ceil(N/2):N/2; >> w = a0 + a1.*cos(2.*pi.*n./N) + a2.*cos(4.*pi.*n./N) + >> a3.*cos(6.*pi.*n./N); >> >> But according to [1], it should be "- a1" and "- a3". HOWEVER, I made >> that change and ended up with a window where the tail is weighted more >> than the center, so I think that Wikipedia might have the wrong >> formula. Agreed? > > It worked for me, but the definition of n I used was also different. > >> Also, this formula inside of blackmanharris.m: >> >> n = -ceil(N/2):N/2; >> >> does not produce the desired result for N odd. > > Correct. > >> >> octave:33> N=7 >> N = 7 >> octave:34> n = -ceil(N/2):N/2 >> n = >> >> -4 -3 -2 -1 0 1 2 3 >> >> Instead of defining 'n' the way the code does, it might be better to >> use the description from the Wiki page that says "w(n) = w_0(n - >> (N-1)/2)", this N not being the same as the N in the lines above. Note >> that blackmanharris.m uses an input L which is the length of window >> and N = L - 1. > > The definition of "n" in the wiki page says "n is an integer, with > values *0 ≤ n ≤ N-1*." The N in the Wiki is the length, equivalent to L in blackmanharris.m. So the N in blackmanharras.m is the same as N-1 in the Wiki.  Confusing, yes. >> >> I think the definition of n inside blackmanharris.m should be: >> >> n = (0:N) - N/2; >> >> Does that produce the result you are expecting James? > > I haven't tested this inside the signal toolbox blackmanharris.m file, > but it yields non integer values of "n" for L = even numbers, N being > then odd, and N/2 resulting in a non integer value. > > My version of blackmanharris.m, that I simply overloaded the system > default with, looks like this; > > function w = blackmanharris (N) > > w = 1; > > a0 = 0.35875; > a1 = 0.48829; > a2 = 0.14128; > a3 = 0.01168; > > for n=0:N-1 > w(n+1) = a0 - a1 * cos(2*pi()*n/(N-1)) + a2 * cos(4*pi()*n/(N-1)) - a3 * > cos(6*pi()*n/(N-1)); > endfor > endfunction; OK, so you are using N as the length.  That matches with the Wiki then.   However, loops are discouraged.  Did you use a loop to avoid a conditional test that N be greater than zero?  Otherwise, I'd suggest the following: function w = blackmanharris (N)      if (N < 1)          error('Window length must be 1 or greater');      elseif (N == 1)          w = 1;      else          a0 = 0.35875;          a1 = 0.48829;          a2 = 0.14128;          a3 = 0.01168;          n=0:N-1;          w = a0 - a1 * cos(2*pi*n./(N-1)) + a2 * cos(4*pi*n./(N-1)) - a3 * cos(6*pi*n./(N-1));      endif endfunction; The result looks similar to what I was getting from the change I suggested in the previous post.  Note one peculiar artifact, which is that changing the phasing of the inputs (theoretically correct) results in a small round off error as reported by Octave: octave:181>     for n=0:N-1   * cos(6*pi()*n/(N-1)); a1 * cos(2*pi()*n/(N-1)) + a2 * cos(4*pi()*n/(N-1)) - a3 >     endfor octave:182> w w =   Columns 1 through 6:     6.0000e-05   5.5645e-02   5.2057e-01   1.0000e+00   5.2058e-01 5.5645e-02   Column 7:     6.0000e-05 The above is indicating 5.2057e-01 and 5.2058e-01 for coefficients, but when I list them in long format, why the rounding occurs isn't evident.   The rounding effect will likely show up somewhere no matter the formula. As to the question Mike raised, I'll follow up with another email. Dan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Octave-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/octave-dev
Open this post in threaded view
|

## Re: fir1 question on symmetry

 In reply to this post by Mike Miller On 05/07/2012 09:26 PM, Mike Miller wrote: > On Mon, May 07, 2012 at 08:54:16PM -0500, Daniel J Sebald wrote: >> Does that produce the result you are expecting James? > > But actually both the current and this behavior do not match ML's > blackmanharris function, at least in the version I have at my disposal. > Can anyone verify? > > I just ran it with a couple different lengths and it always returns an > asymmetric window, whether the length is even or odd.  Can't say whether > this is intentional, other window functions seem to be symmetric. As to the question Mike raises, I'm assuming that the desire is a symmetric window as described in the Wiki and in many theoretical discussions.  However, the Wiki does say: "A common desire is for an asymmetrical window called DFT-even[6] or periodic, which has a single maximum but an even number of samples (required by the FFT algorithm). Such a window would be generated by the Matlab function hann(512,'periodic'), for instance. Here, that window would be generated by N=513 and discarding the 513th element of the \scriptstyle w(n) sequence." Note that 'periodic' is not interpreted in Octave. Dan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Octave-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/octave-dev
Open this post in threaded view
|

## Re: fir1 question on symmetry

 In reply to this post by Daniel Sebald On 08/05/12 13:26, Daniel J Sebald wrote: > On 05/07/2012 09:29 PM, James Steward wrote: >> On 08/05/12 11:54, Daniel J Sebald wrote: >> >>> >>> octave:33> N=7 >>> N = 7 >>> octave:34> n = -ceil(N/2):N/2 >>> n = >>> >>> -4 -3 -2 -1 0 1 2 3 >>> >>> Instead of defining 'n' the way the code does, it might be better to >>> use the description from the Wiki page that says "w(n) = w_0(n - >>> (N-1)/2)", this N not being the same as the N in the lines above. Note >>> that blackmanharris.m uses an input L which is the length of window >>> and N = L - 1. >> >> The definition of "n" in the wiki page says "n is an integer, with >> values *0 ≤ n ≤ N-1*." > > The N in the Wiki is the length, equivalent to L in blackmanharris.m. > So the N in blackmanharras.m is the same as N-1 in the Wiki.   > Confusing, yes. > It is the definition of "n" from the wiki that does not match the way it is defined in the blackmanharris.m file or your proposal (just below) that I was pointing out. >>> >>> I think the definition of n inside blackmanharris.m should be: >>> >>> n = (0:N) - N/2; >>> >>> Does that produce the result you are expecting James? >> >> I haven't tested this inside the signal toolbox blackmanharris.m file, >> but it yields non integer values of "n" for L = even numbers, N being >> then odd, and N/2 resulting in a non integer value. >> >> My version of blackmanharris.m, that I simply overloaded the system >> default with, looks like this; >> >> function w = blackmanharris (N) >> >> w = 1; >> >> a0 = 0.35875; >> a1 = 0.48829; >> a2 = 0.14128; >> a3 = 0.01168; >> >> for n=0:N-1 >> w(n+1) = a0 - a1 * cos(2*pi()*n/(N-1)) + a2 * cos(4*pi()*n/(N-1)) - a3 * >> cos(6*pi()*n/(N-1)); >> endfor >> endfunction; > > OK, so you are using N as the length.  That matches with the Wiki > then.  However, loops are discouraged.  Did you use a loop to avoid a > conditional test that N be greater than zero? I did say my code was not beautifully efficient. >   Otherwise, I'd suggest the following: > > function w = blackmanharris (N) > >     if (N < 1) >         error('Window length must be 1 or greater'); >     elseif (N == 1) >         w = 1; >     else >         a0 = 0.35875; >         a1 = 0.48829; >         a2 = 0.14128; >         a3 = 0.01168; >         n=0:N-1; >         w = a0 - a1 * cos(2*pi*n./(N-1)) + a2 * cos(4*pi*n./(N-1)) - > a3 * cos(6*pi*n./(N-1)); >     endif > > endfunction; > > The result looks similar to what I was getting from the change I > suggested in the previous post.  Note one peculiar artifact, which is > that changing the phasing of the inputs (theoretically correct) > results in a small round off error as reported by Octave: > > octave:181>     for n=0:N-1 >  * cos(6*pi()*n/(N-1)); a1 * cos(2*pi()*n/(N-1)) + a2 * > cos(4*pi()*n/(N-1)) - a3 >>     endfor > octave:182> w > w = > >  Columns 1 through 6: > >    6.0000e-05   5.5645e-02   5.2057e-01   1.0000e+00   5.2058e-01 > 5.5645e-02 > >  Column 7: > >    6.0000e-05 > > The above is indicating 5.2057e-01 and 5.2058e-01 for coefficients, > but when I list them in long format, why the rounding occurs isn't > evident.  The rounding effect will likely show up somewhere no matter > the formula. Nice.  Perhaps this can make it into the next signal processing package? Regards, James. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Octave-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/octave-dev
Open this post in threaded view
|

## Re: fir1 question on symmetry

 In reply to this post by Daniel Sebald On Mon, May 7, 2012 at 11:32 PM, Daniel J Sebald <[hidden email]> wrote: > On 05/07/2012 09:26 PM, Mike Miller wrote: >> >> On Mon, May 07, 2012 at 08:54:16PM -0500, Daniel J Sebald wrote: > > >>> Does that produce the result you are expecting James? >> >> >> But actually both the current and this behavior do not match ML's >> blackmanharris function, at least in the version I have at my disposal. >> Can anyone verify? >> >> I just ran it with a couple different lengths and it always returns an >> asymmetric window, whether the length is even or odd.  Can't say whether >> this is intentional, other window functions seem to be symmetric. > > > As to the question Mike raises, I'm assuming that the desire is a symmetric > window as described in the Wiki and in many theoretical discussions. >  However, the Wiki does say: > > "A common desire is for an asymmetrical window called DFT-even[6] or > periodic, which has a single maximum but an even number of samples (required > by the FFT algorithm). Such a window would be generated by the Matlab > function hann(512,'periodic'), for instance. Here, that window would be > generated by N=513 and discarding the 513th element of the \scriptstyle w(n) > sequence." > > Note that 'periodic' is not interpreted in Octave. Dan, good catch.  The version of ML with signal toolbox I looked at doesn't have the "sflag" optional argument for blackmanharris but does for hann.  Looks like it's been added to some [1],[2],[3] window functions but not those that already take a numeric parameter [4]. I'd say this would be the right fix for the signal package. [1] http://www.mathworks.com/help/toolbox/signal/ref/hann.html[2] http://www.mathworks.com/help/toolbox/signal/ref/blackman.html[3] http://www.mathworks.com/help/toolbox/signal/ref/blackmanharris.html[4] http://www.mathworks.com/help/toolbox/signal/ref/kaiser.html-- mike ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Octave-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/octave-dev
Open this post in threaded view
|

## Re: fir1 question on symmetry

 In reply to this post by James Steward On 05/07/2012 10:50 PM, James Steward wrote: > On 08/05/12 13:26, Daniel J Sebald wrote: [snip] >> The above is indicating 5.2057e-01 and 5.2058e-01 for coefficients, >> but when I list them in long format, why the rounding occurs isn't >> evident. The rounding effect will likely show up somewhere no matter >> the formula. > > Nice. Perhaps this can make it into the next signal processing package? I've created a bug report (3524658) and included a patch.  But I limited the patch to just modifying a line or two because several years ago Mike Gross had previously found the symmetry bug in blackmanharris.m: http://www.mail-archive.com/octave-dev@.../msg01569.htmlI included that patch along with the bug report. We'll use that as a start.  The above patch doesn't fix the additional bug for division by zero when the input length is 1.  I think it is better to do this incrementally.  I searched the signal package directory and see there are about a half dozen routines have a similar construct to blackmanharris.m, namely the division-by-zero bug.  I'm proposing those all be cleaned up in one fell swoop.  Here are some questions in that regard: 1) There are many windows in the signal package that have "win" appended near the end of the name.  Is there a rhyme or reason to doing that?  I mean, there are several more standard windows in the package that don't have "win" associated with the name.  E.g., hanning, blackmanharris, etc.  Should we eliminate the "win" from the pertinent files and rename.   I think people will soon become familiar with the signal routines to not really be confused too much by the window functions.  There aren't that many scripts.  I'd prefer organizing things differently if that is the case, e.g., a separate package for "extra" windows.  I'd prefer dropping the "win".  Other's thoughts? 2) Let's pick a consistent variable for length onside the window script files.  Right now we have "L" in the documentation of some.  Then inside those there is the definition of N = L - 1.  The hanning routine has M as a length in its documentation. 3) All window scripts should test for the special cases of window length (e.g., N = 1).  If there is a user input error, what message should be displayed? 4) Do we want to have an test scripts in these window routines for a sanity check, e.g., the special cases I'm referring to in (3). Anyway, James and Mike, please confirm the patch I've included in bug report (3524658) so that can be moved into the repository sooner rather than later.  From there one or more of us can add new bug reports for further improvements. Dan PS: Ahh, I just found some more discussion this issue by Mike Gross and Peter Lanspeary in the archive.  Peter, Mike, could the two of you please pick up where things left off, remind us what the issue is and attach updated patches to bug report 3524658? https://sourceforge.net/tracker/?func=detail&aid=3524658&group_id=2888&atid=102888If you think there is nothing to do with addressing the symmetry, make a note in the bug report.  If we need to address symmetry with an input option we can do so.  If the asymmetry should be left in we should at least have a note in the code as to why it is there so that future inquisitors don't become confused. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Octave-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/octave-dev
Open this post in threaded view
|

## Re: fir1 question on symmetry

 On Tue, May 8, 2012 at 5:39 AM, Daniel J Sebald <[hidden email]> wrote: > On 05/07/2012 10:50 PM, James Steward wrote: >> >> On 08/05/12 13:26, Daniel J Sebald wrote: > > [snip] > >>> The above is indicating 5.2057e-01 and 5.2058e-01 for coefficients, >>> but when I list them in long format, why the rounding occurs isn't >>> evident. The rounding effect will likely show up somewhere no matter >>> the formula. >> >> >> Nice. Perhaps this can make it into the next signal processing package? > > > I've created a bug report (3524658) and included a patch.  But I limited the > patch to just modifying a line or two because several years ago Mike Gross > had previously found the symmetry bug in blackmanharris.m: > > http://www.mail-archive.com/octave-dev@.../msg01569.html> > I included that patch along with the bug report. > > We'll use that as a start.  The above patch doesn't fix the additional bug > for division by zero when the input length is 1.  I think it is better to do > this incrementally.  I searched the signal package directory and see there > are about a half dozen routines have a similar construct to > blackmanharris.m, namely the division-by-zero bug.  I'm proposing those all > be cleaned up in one fell swoop. Agreed. > Here are some questions in that regard: > > 1) There are many windows in the signal package that have "win" appended > near the end of the name.  Is there a rhyme or reason to doing that?  I > mean, there are several more standard windows in the package that don't have > "win" associated with the name.  E.g., hanning, blackmanharris, etc.  Should > we eliminate the "win" from the pertinent files and rename.  I think people > will soon become familiar with the signal routines to not really be confused > too much by the window functions.  There aren't that many scripts.  I'd > prefer organizing things differently if that is the case, e.g., a separate > package for "extra" windows.  I'd prefer dropping the "win".  Other's > thoughts? I believe we are using the correct naming convention. http://www.mathworks.com/help/toolbox/signal/ref/f9-131178c.html#f9-140546> 2) Let's pick a consistent variable for length onside the window script > files.  Right now we have "L" in the documentation of some.  Then inside > those there is the definition of N = L - 1.  The hanning routine has M as a > length in its documentation. Agreed. > 3) All window scripts should test for the special cases of window length > (e.g., N = 1).  If there is a user input error, what message should be > displayed? > > 4) Do we want to have an test scripts in these window routines for a sanity > check, e.g., the special cases I'm referring to in (3). Yes and yes, tests for edge cases and also tests for invalid arguments to make sure only correct inputs are accepted.  See for example triang.m. > Anyway, James and Mike, please confirm the patch I've included in bug report > (3524658) so that can be moved into the repository sooner rather than later. >  From there one or more of us can add new bug reports for further > improvements. Works for me.  No worse than existing behavior, now produces symmetric filter only, but change in indexing sets the stage for future changes.  Also current asymmetric window is incorrect, I checked some examples against other window libraries. I had a problem downloading your patch from SF but I applied the one from the mailing list archive, I assume they're the same.  This is a good incremental first step, I'll check this in later today if I don't hear any objections. -- mike ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Octave-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/octave-dev
Open this post in threaded view
|

## Re: fir1 question on symmetry

Open this post in threaded view
|

## Re: fir1 question on symmetry

 On 05/10/2012 01:12 AM, Mike Gross wrote: > I had been using my local copy of the blackmanharris function and didn't > realize that my patch was not applied. > > I think that the root issue is that the previous implementer of some or > all of the window functions assumed that the periodic output was the > correct behavior. My bias is to match MatLab behavior which I assume > produces symmetric coefficients. Has this been verified? > > My intention had been to ensure that all of the window functions > returned symmetric coefficients and valid values for integer lengths > greater than zero but somewhere along the line it fell off of my radar. > It seems like James, Daniel and Mike are on top of this but I could > easily assist if it seems worthwhile. OK.  I think there is a start on this from Peter: http://www.mail-archive.com/octave-dev@.../msg01576.htmlthat attempts the "periodic" and "symmetric" distinction.  I suggest one of us freshen that patch with the current SVN source and attach it to a bug report.  Once we agree on the behavior and appearance of welchwin.m then we'll search for several windows of the same nature and do a similar mod.  When we're done we'll move the patch with all changes into SVN. I suggest adding some test cases in the script files to verify it is in fact symmetric or period depending on the choice.  I demo that plots side by side the spectral characteristics of the two types might be nice.  It would help the user understand the difference between the two options. I might be unavailable until early next week. Dan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Octave-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/octave-dev
Open this post in threaded view
|