[SciPy-user] firwin upgrades

Stéfan van der Walt stefan@sun.ac...
Fri May 1 12:46:10 CDT 2009


Hi Tom

2009/4/26 Tom K. <tpk@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

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

Regards
Stéfan


More information about the SciPy-user mailing list