[SciPy-user] firwin upgrades
Stéfan van der Walt
Fri May 1 12:46:10 CDT 2009
2009/4/26 Tom K. <firstname.lastname@example.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
> 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.
> 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?
More information about the SciPy-user