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. ------------------------------------------------------------------------------ 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
