[Scipy-tickets] [SciPy] #902: need high, stop, pass options to signal.firwin

SciPy Trac scipy-tickets@scipy....
Wed Nov 3 21:19:43 CDT 2010

#902: need high, stop, pass options to signal.firwin
 Reporter:  tpk@…                 |       Owner:  somebody    
     Type:  enhancement           |      Status:  needs_review
 Priority:  normal                |   Milestone:  0.9.0       
Component:  scipy.signal          |     Version:  0.7.0       
 Keywords:                        |  

Comment(by tpk@…):

 Yeah, it felt a little funny to me too ... see the original proposals at
 I don't like in what we ended up with how for a multiband, the btype
 applies to the last band and you have to work backwards from there - seems
 backwards to me.

 Some principles:
  - "a notation that allows the reader of code to see what is happening
 without examining the API of firwin" (from Stefan)
  - one way, or one main way at least, to do things

 Some comments on your proposed APIs.
  - API1. that's what we ended up with right?  worth considering
  - API2. I like the first band is a passband idea, but kind of hard to
 tell the intention by looking at it.
  - API3. I don't get this one, for example I am not sure why highpass with
 cutoff [.5, 1], [0, .5], and [0, .5, 1] all are the same.

 What do you think of a multiband API where the user may specify a list of
 (left, right) tuples for the pass bands?  One thing I like about that idea
 is that it most naturally fits the algorithm, since only the passbands
 contribute to the impulse response.  Perhaps it is the only way that
 should be provided by firwin to design multiband filters, besides the
 backwards compatible cutoff.

 Perhaps firwin could support two types, either simple or multiband:
   1. cutoff, btype: a scalar between 0 and 1, and a string either 'low'
 (default) or 'high'
   2. bands: a list of tuples for passbands
 I think this more clearly separates the multiband from the lowpass and
 highpass - but it leaves off a simple bandpass and bandstop case.
 Defaults would be cutoff=None, btype='low', bands=None; if bands is a
 list, cutoff and btype are ignored, whereas if bands is None, cutoff must
 be specified.

 Maybe going with a "fir1" equivalent would be a good idea - why come up
 with a new, arbitrary set of argument conventions that is hard to
 remember?   I am also starting to gravitate toward some of the ideas
 there: 0 and 1 are not allowed, so the cutoff list is always clear, and
 the btype could be 'pass' or 'stop' or 'DC-0' or 'DC-1'... starting to
 make sense to me.  Seems to pass Stefan's readability test too.

 So, I would propose whatever you like for firwin that is backwards
 compatible, and a new wrapper called fir1 with fir1's argument

Ticket URL: <http://projects.scipy.org/scipy/ticket/902#comment:21>
SciPy <http://www.scipy.org>
SciPy is open-source software for mathematics, science, and engineering.

More information about the Scipy-tickets mailing list