fir1 question on symmetry

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

fir1 question on symmetry

James Steward
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

James Steward
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

Daniel Sebald
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

Mike Miller
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

James Steward
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

Daniel Sebald
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

Daniel Sebald
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

James Steward
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

Mike Miller
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

Daniel Sebald
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

Mike Miller
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

Mike Gross
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

Daniel Sebald
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

Mike Miller
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

Daniel Sebald
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
Reply | Threaded
Open this post in threaded view
|

Re: fir1 question on symmetry

Mike Miller
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