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 |
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 |
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 |
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 |
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: 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 It worked for me, but the definition of n I used was also different. Also, this formula inside of blackmanharris.m: Correct.
The definition of "n" in the wiki page says "n is an integer, with values 0 ≤ n ≤ N-1."
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 |
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 |
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 |
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 |
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 |
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.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. 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=102888 If 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 |
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 |
In reply to this post by Daniel Sebald
On 5/8/2012 2:39 AM, Daniel J Sebald 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. 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=102888 > > If 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. > 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. 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 |
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.html that 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 |
On Thu, May 10, 2012 at 4:17 AM, Daniel J Sebald <[hidden email]> wrote:
> 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? Depends on your version :) I have a version that generates DFT-style windows for some (blackmanharris and nuttallwin) and symmetric filter-style windows for the others. The most up-to-date ML docs on the web indicate that the symmetric|periodic argument has been added to these and the default switched to symmetric for those that weren't. I think this newest behavior is what we are saying we should achieve. >> 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.html > > that 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. Dan, just to clarify, are you saying there are fixes to be made to welchwin or are you saying this should be the gold standard to use as a starting point for the others? I think it looks mostly complete, here's what I'd change: * tweak the arg 2 parsing a bit (get rid of unnecessary size and isempty, use strncmp, rearrange) * allow any L>0 (I see Peter's argument about utility but there is a valid answer for L=1 or 2) * return a column vector * add test cases > 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. Good idea. In the mean time I've already updated all window functions to have the same length argument name and started updating the help text, especially for those that don't have properly formatted help. -- 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 |
On 05/10/2012 07:06 AM, Mike Miller wrote:
> On Thu, May 10, 2012 at 4:17 AM, Daniel J Sebald<[hidden email]> wrote: >> 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? > > Depends on your version :) I have a version that generates DFT-style > windows for some (blackmanharris and nuttallwin) and symmetric > filter-style windows for the others. The most up-to-date ML docs on > the web indicate that the symmetric|periodic argument has been added > to these and the default switched to symmetric for those that weren't. > I think this newest behavior is what we are saying we should achieve. > >>> 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.html >> >> that 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. > > Dan, just to clarify, are you saying there are fixes to be made to > welchwin or are you saying this should be the gold standard to use as > a starting point for the others? Fixes and cleaning up. > I think it looks mostly complete, here's what I'd change: > * tweak the arg 2 parsing a bit (get rid of unnecessary size and > isempty, use strncmp, rearrange) Yes. Use the strcmp and routines for getting the index without all the conditional statements. Essentially the same thing, but using the versatile commands of the language cleans things up. > * allow any L>0 (I see Peter's argument about utility but there is a > valid answer for L=1 or 2) I agree. Even if length is 1 and is an uneventful window, it still meets the definition of symmetry and circular periodicity. No reason to rule those out. > * return a column vector I'm OK with that. > * add test cases Tests are good. All that is needed I think is a case which has enough variation, then test something like for N=8:9 w = welchwin(N, 'symmetric'); if sum(w - flipud(w)) > eps error('Failed symmetry test'); end end Or whatever similar error mechanism is used in those demo scripts. >> 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. > > Good idea. > > In the mean time I've already updated all window functions to have the > same length argument name and started updating the help text, > especially for those that don't have properly formatted help. OK, thank you. What about the names of the files? "welch" would be fine for me. Once someone has done enough DSP-like work, it becomes clear "welch" is a window without needing the "win" appended to the name. 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 |
On Thu, May 10, 2012 at 7:30 PM, Daniel J Sebald <[hidden email]> wrote:
> What about the names of the files? "welch" would be fine for me. Once > someone has done enough DSP-like work, it becomes clear "welch" is a window > without needing the "win" appended to the name. When I think Welch and DSP I'm thinking Welch periodogram estimation, which is pwelch. And I see there's also a welch_test in the statistics library. I'd say leave it as welchwin :) And as for the others, they all match the names of their ML counterparts. -- 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 |
Free forum by Nabble | Edit this page |