discuss [bug #43305] Hamming etc. windows are wrong

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

discuss [bug #43305] Hamming etc. windows are wrong

Doug Stewart-4
Rik asked me to start a discussion here about how to fix this bug.

 The real question is:   Should we do as Matlab did or should we make the default  
 be the more mathematically correct method.

 I am arguing for the mathematically correct method as the default.
 ( I will be happy even if I loose  the argument)

I will post my argument in the next chapter :-)

Comment are welcome.


--
DASCertificate for 206392

Reply | Threaded
Open this post in threaded view
|

Re: discuss [bug #43305] Hamming etc. windows are wrong

Doug Stewart-4


On Tue, Dec 30, 2014 at 12:48 PM, Doug Stewart <[hidden email]> wrote:
Rik asked me to start a discussion here about how to fix this bug.

 The real question is:   Should we do as Matlab did or should we make the default  
 be the more mathematically correct method.

 I am arguing for the mathematically correct method as the default.
 ( I will be happy even if I loose  the argument)

I will post my argument in the next chapter :-)

Comment are welcome.



 The technical reason that our window functions are wrong was
 given by the original poster, Oscar Ruitt.

  The Wikipedia page  down at
       Filter design:
 Shows 3 different methods 
   -- Matlab symmetric
   -- Matlab Periodic
   -- DFT-even

 DFT-even is what I have been thinking as the "correct" 
 way to go.

  I dont have Matlab so, would someone run
 hann(8) on matlab and see if the first number is non zero?

Octave gives
hann(8)
ans =

   0.00000
   0.18826
   0.61126
   0.95048
   0.95048
   0.61126
   0.18826
   0.00000


 

Reply | Threaded
Open this post in threaded view
|

Re: discuss [bug #43305] Hamming etc. windows are wrong

Mike Miller
On Tue, Dec 30, 2014 at 13:58:49 -0500, Doug Stewart wrote:

>
>
> On Tue, Dec 30, 2014 at 12:48 PM, Doug Stewart <[hidden email]>
> wrote:
>>
>> Rik asked me to start a discussion here about how to fix this bug.
>>
>>  The real question is:   Should we do as Matlab did or should we make the
>> default
>>  be the more mathematically correct method.
>>
>>  I am arguing for the mathematically correct method as the default.
>>  ( I will be happy even if I loose  the argument)
>>
>> I will post my argument in the next chapter :-)
>>
>> Comment are welcome.
>>
>>
>
>  The technical reason that our window functions are wrong was
>  given by the original poster, Oscar Ruitt.
>
>   The Wikipedia page  down at
>        Filter design:
>        http://en.wikipedia.org/wiki/Window_function
>  Shows 3 different methods
>    -- Matlab symmetric
>    -- Matlab Periodic
>    -- DFT-even
>
>  DFT-even is what I have been thinking as the "correct"
>  way to go.

I think the most important criterion for this specific case of the
window functions is to be compatible with Matlab. The law of least
surprise says the default should return a symmetric window with
properties equivalent to Matlab, this is correct and useful for
digital filter design. The "periodic" option should be accepted, at
least for those functions where it is accepted in Matlab, and return
the truncated n+1 window, useful for windowing with DFTs.

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: discuss [bug #43305] Hamming etc. windows are wrong

Julien Bect
In reply to this post by Doug Stewart-4
Le 30/12/2014 19:58, Doug Stewart a écrit :
>   I dont have Matlab so, would someone run
>  hann(8) on matlab and see if the first number is non zero?

% Matlab R2012a

 >> format long
 >> hann(8)

ans =

                    0
    0.188255099070633
    0.611260466978157
    0.950484433951210
    0.950484433951210
    0.611260466978157
    0.188255099070633
                    0

Reply | Threaded
Open this post in threaded view
|

Re: discuss [bug #43305] Hamming etc. windows are wrong

Doug Stewart-4


On Tue, Dec 30, 2014 at 3:35 PM, Julien Bect <[hidden email]> wrote:
Le 30/12/2014 19:58, Doug Stewart a écrit :
  I dont have Matlab so, would someone run
 hann(8) on matlab and see if the first number is non zero?

% Matlab R2012a

>> format long
>> hann(8)

ans =

                   0
   0.188255099070633
   0.611260466978157
   0.950484433951210
   0.950484433951210
   0.611260466978157
   0.188255099070633
                   0



--
Thanks Julien
 
So wikipedia is wrong in the graphs that show the 3 curves. 

I will put together some graphs and FFT pictures of what is happening.
Doug


Reply | Threaded
Open this post in threaded view
|

Re: discuss [bug #43305] Hamming etc. windows are wrong

Rik-4
In reply to this post by Doug Stewart-4
On 12/30/2014 12:26 PM, [hidden email] wrote:
Subject:
Re: discuss [bug #43305] Hamming etc. windows are wrong
From:
Mike Miller [hidden email]
Date:
12/30/2014 11:56 AM
To:
Doug Stewart [hidden email]
CC:
Octave Maintainers List [hidden email]
List-Post:
[hidden email]
Precedence:
list
MIME-Version:
1.0
References:
[hidden email] [hidden email]
In-Reply-To:
[hidden email]
Message-ID:
[hidden email]
Content-Type:
text/plain; charset=UTF-8
Message:
6

On Tue, Dec 30, 2014 at 13:58:49 -0500, Doug Stewart wrote:
>
>
> On Tue, Dec 30, 2014 at 12:48 PM, Doug Stewart [hidden email]
> wrote:
>>
>> Rik asked me to start a discussion here about how to fix this bug.
>>
>>  The real question is:   Should we do as Matlab did or should we make the
>> default
>>  be the more mathematically correct method.
>>
>>  I am arguing for the mathematically correct method as the default.
>>  ( I will be happy even if I loose  the argument)
>>
>> I will post my argument in the next chapter :-)
>>
>> Comment are welcome.
>>
>>
>
>  The technical reason that our window functions are wrong was
>  given by the original poster, Oscar Ruitt.
>
>   The Wikipedia page  down at
>        Filter design:
>        http://en.wikipedia.org/wiki/Window_function
>  Shows 3 different methods
>    -- Matlab symmetric
>    -- Matlab Periodic
>    -- DFT-even
>
>  DFT-even is what I have been thinking as the "correct"
>  way to go.
I think the most important criterion for this specific case of the
window functions is to be compatible with Matlab. The law of least
surprise says the default should return a symmetric window with
properties equivalent to Matlab, this is correct and useful for
digital filter design. The "periodic" option should be accepted, at
least for those functions where it is accepted in Matlab, and return
the truncated n+1 window, useful for windowing with DFTs.

Shouldn't we give users all three choices?  The two Matlab options have to be there for compatibility, but the last one seems most mathematically correct and should at least be offered.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: discuss [bug #43305] Hamming etc. windows are wrong

Peter L. Soendergaard
In reply to this post by Doug Stewart-4
Please have a look at the firwin function in LTFAT. You need to fftshift the output to get the right sequence of numbers for a normal window. There you can find all the standard windows.

We put a lot of effort into getting the numbers correct for firwin, because you cannot get perfect reconstruction in an MDCT (used for MP3 encoding) unless the symmetry and spacing is correct.

Cheers,
Peter

(and sorry, my phone suck at bottom posting)

On 30. dec. 2014 21.56.12 CET, Doug Stewart <[hidden email]> wrote:


On Tue, Dec 30, 2014 at 3:35 PM, Julien Bect <[hidden email]> wrote:
Le 30/12/2014 19:58, Doug Stewart a écrit :
  I dont have Matlab so, would someone run
 hann(8) on matlab and see if the first number is non zero?

% Matlab R2012a

>> format long
>> hann(8)

ans =

                   0
   0.188255099070633
   0.611260466978157
   0.950484433951210
   0.950484433951210
   0.611260466978157
   0.188255099070633
                   0



--
Thanks Julien
 
So wikipedia is wrong in the graphs that show the 3 curves. 

I will put together some graphs and FFT pictures of what is happening.
Doug



--
Sendt fra min Android telefon med K-9 Mail. Undskyld hvis jeg er lidt kortfattet.
Reply | Threaded
Open this post in threaded view
|

Re: discuss [bug #43305] Hamming etc. windows are wrong

Doug Stewart-4


On Tue, Dec 30, 2014 at 3:35 PM, Julien Bect <[hidden email]> wrote:
Le 30/12/2014 19:58, Doug Stewart a écrit :
  I dont have Matlab so, would someone run
 hann(8) on matlab and see if the first number is non zero?

% Matlab R2012a

>> format long
>> hann(8)

ans =

                   0
   0.188255099070633
   0.611260466978157
   0.950484433951210
   0.950484433951210
   0.611260466978157
   0.188255099070633
                   0



--
Thanks Julien
 
So wikipedia is wrong in the graphs that show the 3 curves. 

I will put together some graphs and FFT pictures of what is happening.
Doug





 Julien  you might be interested in my error messages

pkg install -forge ltfat
configure: WARNING: Portaudio lib not found. Disabling support of the block processing framework.
ar: creating libltfat.a
ar: creating libltfatf.a

warning: doc_cache_create: unusable help text found in file'playrec'
For information about changes from previous versions of theltfat package, run 'news ltfat'.






--
DAS

Reply | Threaded
Open this post in threaded view
|

Re: discuss [bug #43305] Hamming etc. windows are wrong

Jerry
In reply to this post by Doug Stewart-4

On Dec 30, 2014, at 10:48 AM, Doug Stewart <[hidden email]> wrote:

Rik asked me to start a discussion here about how to fix this bug.

 The real question is:   Should we do as Matlab did or should we make the default  
 be the more mathematically correct method.

 I am arguing for the mathematically correct method as the default.
 ( I will be happy even if I loose  the argument)

I will post my argument in the next chapter :-)

Comment are welcome.

I just moments ago wrote a response to Doug Stewart's note in a related thread, "Ltfat tria window", in which he gets a window (triangle in his case) which is rotated from what might be expected. That is, the triangle window is high at the ends and low in the middle. Of course this is convenient if one wants to apply it to a normally-indexed DFT result (0 .. N - 1) whereby the high frequencies are attenuated more than the low frequencies. As I note there, both types of windows are applicable, typically unrotated windows for applying to time series and rotated windows for applying to (unrotated) frequency series.

So while we are attending to fixing up Octave's window functions I think we should add another option to return a rotated version.

I suppose it's obvious but by rotated I mean circularly shifted by N / 2 or N / 2 - 1 depending on the direction of the shift.

Jerry

P.S. Here's a clarification on my name(s). Sorry for any confusion.

I am the OP on the Hamming etc. window bug; my login name is Oscar Ruitt which is an alias. (It's a joke in English if you say it quickly.) My list e-mail address usually includes lanceboyle which is another joke. My real name is Jerry Bauck and I normally just sign as Jerry so as to avoid polluting my internet namespace.
Reply | Threaded
Open this post in threaded view
|

Re: discuss [bug #43305] Hamming etc. windows are wrong

Doug Stewart-4


On Fri, Jan 2, 2015 at 7:38 PM, Jerry <[hidden email]> wrote:

On Dec 30, 2014, at 10:48 AM, Doug Stewart <[hidden email]> wrote:

Rik asked me to start a discussion here about how to fix this bug.

 The real question is:   Should we do as Matlab did or should we make the default  
 be the more mathematically correct method.

 I am arguing for the mathematically correct method as the default.
 ( I will be happy even if I loose  the argument)

I will post my argument in the next chapter :-)

Comment are welcome.

I just moments ago wrote a response to Doug Stewart's note in a related thread, "Ltfat tria window", in which he gets a window (triangle in his case) which is rotated from what might be expected. That is, the triangle window is high at the ends and low in the middle. Of course this is convenient if one wants to apply it to a normally-indexed DFT result (0 .. N - 1) whereby the high frequencies are attenuated more than the low frequencies. As I note there, both types of windows are applicable, typically unrotated windows for applying to time series and rotated windows for applying to (unrotated) frequency series.

So while we are attending to fixing up Octave's window functions I think we should add another option to return a rotated version.

I suppose it's obvious but by rotated I mean circularly shifted by N / 2 or N / 2 - 1 depending on the direction of the shift.

Jerry

P.S. Here's a clarification on my name(s). Sorry for any confusion.

I am the OP on the Hamming etc. window bug; my login name is Oscar Ruitt which is an alias. (It's a joke in English if you say it quickly.) My list e-mail address usually includes lanceboyle which is another joke. My real name is Jerry Bauck and I normally just sign as Jerry so as to avoid polluting my internet namespace.



-- 

   Things are gradually getting clearer in my mind as to the confusion between  different systems.
1) LTFAT windows are rotated from pkg signal windows.

2) The triang window from signal pkg is a modified triangle window from the Harris documentation.

3) The bartlett window from signal pkg is a triangle window from the Harris documentation.

I am used to the Harris document from 1978. I taught from it for many years, so when we started talking about FFTs and widows my mined just goes to this document, which I got in 1982!!!!

Attaches is a simple overview of the problem.
I am now going to look in depth at the FFT of each window and see if there is any really compelling reason to use one version as the default.

Also I agree that we should include option 3 -- "rotated".

Stay tuned!
Doug

P.S.  thanks for clarifying your name Jerry.



windows_for_Octave_ch2.pdf (96K) Download Attachment