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@lists.sourceforge.net/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
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev

Reply via email to