[SciPy-user] firwin upgrades

[Tom K.]

Stéfan van der Walt wrote:
> 
> Hi Tom
> 
> 2009/4/26 Tom K. <tpk at kraussfamily.org>:
>> 1) add "btype" kwarg after cutoff that may be any key of the band_dict
>> 2) Allow cutoff to be an arbitrary length list.  Only need a boolean to
>> 3) Same as option 2), but instead of a new boolean argument, allow "0" as
>>
>> What are your preferences from the above (or, suggest an alternative)?
> 
> My preferences is for a notation that allows the reader of code to see
> what is happening without examining the API of firfilter.   So,
> suggestion 1 with the prerequisite that the user must specify the
> filter type appeals to me:
> 
> firfilter([0, 0.1], type='pass') # low-pass
> firfilter([0, 0.1], type='stop') # high-pass
> 
> firfilter([0.1, 0.2], type='pass') # band-pass filter
> firfilter([0.1, 0.2], type='stop') # band-stop filter
> 

Thanks for the suggestion Stéfan!

I think readability of the client code is a great prerequisite.  However,
what you suggest is not backwards compatible with the current firwin
behavior - and I was talking about upgrading firwin rather than adding a new
function.  Are you proposing a new function?  Or proposing that the upgrades
not be backwards compatible?


Stéfan van der Walt wrote:
> 
>> NULL AT NYQUIST ISSUE
>>  a) issue a warning, increase length by 1, and return the longer filter
>> [this is the behavior of another popular signal processing package]
>>  b) design the filter anyway, and issue either an error if noScale is
>> False
>> (since the scaling would cause a divide by 0 - see proposal below) or a
>> warning if noScale is True.
> 
> Not sure about this.  Is there an elegant solution?  (a) seems as good as
> any.
> 

Hmm.  I think bumping up the filter order seems kind of slimy now that I
think about it.  If someone asks for a filter of a certain (even) length,
but also asks for it to be a highpass filter scaled so that the response at
Nyquist is 1, then I think that is a bad choice and an error should result.


Stéfan van der Walt wrote:
> 
>> SUPPORT FOR NO SCALING
>> Currently, the filter is scaled so that the DC value of the filter is
>> unity.
>> This filter no longer minimizes the integral of the square of the error
>> because the scaling is not natural.  I propose we provide a boolean
>> "noScale" argument that will allow the filter to float according to the
>> actual least-squares filter.   How does that sound?
> 
> Sure, as long as we avoid the camelCaps :-)  In your experience, is
> "no_scale=False" the most common behaviour?
> 

The scaling is the default behavior which is meant AFAIK to avoid a problem
where the bandwidth is very narrow and the filter length is very small - but
I think it is misleading because you really end up scaling up the filter and
moving the cutoff frequency in that case.

Here's an example - note the scaling in front of sinc of 0.05 is equal to
the Nyquist-normalized cutoff, in order to get a least-squares approximation
to a passband of "1":

h=.05*special.sinc(.05*(numpy.arange(11)-5))
H=numpy.fft.fft(h, 1000)
h1=.05*special.sinc(.05*(numpy.arange(101)-50))
H1=numpy.fft.fft(h1, 1000)
plot(abs(H))
plot(abs(H1))

In the plot, the frequency response of the long length 101 filter is close
to the desired value of 1 across the narrow pass band.  But the frequency
response H of the short length 11 filter only comes up to 0.5. The current
scaling behavior will bring this value up to exactly 1.  I am proposing we
add an option to allow users of this function to avoid this scaling, so they
can decide whether to tack down the magnitude in this way for themselves.

I now prefer a "scale" flag which defaults to True, somehow noScale with a
default of False seems like a double negative.  This also avoids the
camelCaps ;-)

Cheers,
  Tom K.
-- 
View this message in context: http://www.nabble.com/firwin-upgrades-tp23246480p23350618.html
Sent from the Scipy-User mailing list archive at Nabble.com.