Are odd-length window functions supposed to be always symmetrical? (Trac #1665)

[scipy-gitbot]

Original ticket http://projects.scipy.org/scipy/ticket/1665 on 2012-05-30 by @endolith, assigned to @cournape.

The window functions in scipy.signal have a sym option for producing symmetric windows or periodic windows, but if you create a periodic window of an odd size, it gives identical output to a symmetric window. This is in the code, but is it right? It doesn't match Matlab's behavior, as described [https://ccrma.stanford.edu/~jos/sasp/Matlab_Hamming_Window.html here].

If it's right, it should be documented why it works this way

>> hamming(3) % same in Matlab and Octave
ans =
    0.0800
    1.0000
    0.0800
>> hamming(3,'symmetric') % Matlab only
ans =
    0.0800
    1.0000
    0.0800
>> hamming(3,'periodic') % Matlab only
ans =
    0.0800
    0.7700
    0.7700
>> hamming(4) % same in Matlab and Octave
ans =
    0.0800
    0.7700
    0.7700
    0.0800

SciPy:

In [2]: hamming(3)
Out[2]: array([ 0.08,  1.  ,  0.08])

In [3]: hamming(3,sym=True)
Out[3]: array([ 0.08,  1.  ,  0.08])

In [4]: hamming(3,sym=False)
Out[4]: array([ 0.08,  1.  ,  0.08])

In [5]: hamming(4)
Out[5]: array([ 0.08,  0.77,  0.77,  0.08])

In [6]: hamming(4, sym=True)
Out[6]: array([ 0.08,  0.77,  0.77,  0.08])

In [7]: hamming(4, sym=False)
Out[7]: array([ 0.08,  0.54,  1.  ,  0.54])

[scipy-gitbot]

@endolith wrote on 2012-05-30

and by "in the code" I mean it checks if not sym and not odd before generating the periodic version, so it would seem intentional, at least.

[rgommers]

More comments and links to discussions on the Octave bug tracker and on Wikipedia in gh-4551 (closed as duplicate of this issue).

[endolith]

So does anyone have an argument in favor of the way it is now? I haven't seen one.

As I said in the other issue, this was added Nov 2001 in c910a76 by @teoliphant . I don't see any explanation of why it was done that way.

Typically filter design uses odd-length symmetrical windows, and FFT analysis uses even-length "periodic" or "DFT-even" windows, so it wouldn't typically be run into, but I think it's incorrect.

From Harris:

To distinguish this symmetry from conventional evenness we will refer to it as DFT-even (ie., a conventional even sequence with the right end point removed).

...

We will now catalogue some well-known (and some not well-known) windows. ... All the windows will be presented as even (about the origin) sequences with an odd number of points. To convert the window to DFT-even, the right end point will be discarded and the sequence will be shifted so that the left end point coincides with the origin.

One of the properties of "DFT-even" windows is that the DFT "samples exhibit an imaginary component equal to zero". This is true for even-length sym=False but not for odd-length, so I think odd-length is incorrect:

fft(bartlett(6, False))
Out[11]: 
array([ 3.00000000+0.j, -1.33333333-0.j,  0.00000000-0.j, -0.33333333+0.j,
        0.00000000+0.j, -1.33333333+0.j])

fft(bartlett(6, True))
Out[12]: 
array([ 2.4+0.j        , -1.2-0.69282032j,  0.0+0.j        ,
       -0.0+0.j        ,  0.0-0.j        , -1.2+0.69282032j])

fft(bartlett(5, False))
Out[13]: 
array([ 2.00000000+0.j        , -1.05901699-0.76942088j,
        0.05901699+0.18163563j,  0.05901699-0.18163563j,
       -1.05901699+0.76942088j])

fft(bartlett(5, True))
Out[14]: 
array([ 2.00000000+0.j        , -1.05901699-0.76942088j,
        0.05901699+0.18163563j,  0.05901699-0.18163563j,
       -1.05901699+0.76942088j])

It would work out if we did odd and even length the same way:

fft(bartlett(6, True)[:5])
Out[15]: 
array([ 2.4000000+0.j, -1.0472136-0.j, -0.1527864-0.j, -0.1527864+0.j,
       -1.0472136+0.j])

Numpy discussion thread from 2014 said

I can't see any reason this should be limited to even-length windows. Like I said in my original note, the principal applies regardless of even- or odd-length windows.

and no one made a counterargument.

[larsoner]

Just looking at this now, I agree it does seem incorrect. And we're inconsistent with MATLAB, too, right?

[endolith]

I don't have matlab but yes I think it's inconsistent.

@ewmoore When you added tests for the exponential window, were you just going with the status quo?

[endolith]

Prabhu 2014 - "Window functions and their applications in signal processing" has a section 5.2.28 "Odd and Even-Length Windows" about converting odd-length windows to even-length for use with FFTs, and uses the symmetric form for both odd and even, as sym=True currently does:

Herschel Interactive Processing Environment uses the periodic asymmetrical form for both odd and even, as we're proposing for sym=False:

(They also have options to normalize by amplitude, area, or energy, which might be good to have.)

[larsoner]

From Octave (verified to be the same as MATLAB):

>> hamming(5, 'symmetric')
ans =

   0.080000
   0.540000
   1.000000
   0.540000
   0.080000

>> hamming(5, 'periodic')
ans =

   0.080000
   0.397852
   0.912148
   0.912148
   0.397852

Let me know if you want any other values to test against, but it sounds like we've converged on this as a bug and you've found the right refs/solutions.

[larsoner]

Also +1 for adding normalization options if someone happens to be sufficiently motivated to do it :)