[SciPy-dev] RFR: #902 firwin upgrades

[Charles R Harris]

On Mon, May 11, 2009 at 7:44 PM, Tom K. <tpk at kraussfamily.org> wrote:

> Charles R Harris <charlesr.harris <at> gmail.com> writes:
>
> >
> >
> > On Sun, May 10, 2009 at 8:41 PM, Tom K. <tpk <at> kraussfamily.org>
> wrote:
> > (I sent this to scipy-dev <at> scipy.org, thinking it would appear here,
> > I am horribly confused - sorry for the duplication
> > SIMPLE REVIEW NEEDED - SINGLE FUNCTION
> > Link to Trac ticket:  http://projects.scipy.org/scipy/ticket/902
> > This is adding a highpass, bandpass, bandstop, and multiband capability
> to
> > signal.firwin.  I submitted a patch attached to the ticket to
> > filter_design.py.
> > I also added a test class in tests/test_filter_design.py.
> > Let me know if there are any problems with the patch as this is my first
> patch
> > to scipy and I am new to SVN.
> >
> >
> > I think class BandPass is too general a name for a method based on
> windowing.
> > Have you looked at the remez filter design? You can design the type of
> > filters you are talking about using it also.
> > Chuck
>
> For PassBand, which of these options sounds best:
>  1) rename to _PassBand, or FirwinPassBand
>  2) make local to firwin function
>  3) remove class altogether and just go with a list of (left, right) tuples
>

I can't decide at the moment ;) We could put all that stuff in a submodule
with win in it somewhere. If we go that route the name is less important.
Too bad something like FIRPassBandFilterDesignedByWindowingImpulseResponse
is a bit on the lengthy side...


>
> I hadn't seen remez as the wrapper is in signaltools, not filter_design,
> but
> thanks for the pointer.  See this thread
> http://www.nabble.com/firwin-upgrades-td23246480.html for discussion about
> the interface to firwin.
>

On the Nyquist problem with even length filters I'd be inclined to raise an
error.


> The question I have, what is the right way to provide a convenient
> shorthand
> for describing a multiband filter with just a vector?  The Signal
> Processing
> Toolbox has this divergence which maybe we want to avoid.  E.g. fir1 takes
> a
> list of band edges and you leave 0 and 1 off (they are present implicitly)
> and the magnitudes - which are not required to be specified by the user -
> alternate between 1 and 0; the stop, high, and DC-0 options
> change the magnitude to start at 0 instead (whereas pass, low, DC-1 start
> with the default magnitude of 1).  Remez and firls take only band edges
> in pairs and require the same for the magnitude - this allows for
> a piece-wise linear desired function with unspecified regions in between.
> I haven't looked at the newly submitted fir2 (which is sitting in a trac
> issue)
> but the Signal Processing Toolbox has a list of edges and magnitudes with
> 0 and 1 implicit again IIRC.  fir2 doesn't require paired bands, you just
> specify a piecewise linear function and that gets interpolated over the
> entire
> band and inverted to the impulse domain.
>

I think the lower level stuff should be quite general. Upper level
interfaces can simplify things for folks who just want quick and dirty. I
don't know much about the signal processing toolbox, if that is the
functionality we are shooting for.


>
> The more I think about it, the functions seem slightly different in the
> ways that the algorithms work and so it makes some sense that they each
> accept arguments that are tailored to be the most natural for that
> algorithm.
>
> It looks like remez in scipy takes only constant bands.  Hence it may make
> sense to unify it with firwin.  firwin would then allow varying amplitudes
> (the feature I added has them all the same).  The cost is some simplicity,
> but perhaps some "smarts" could be added that make the magnitude vector
> implicit if unspecified (which could work for remez in the same way).
> Is that what you would propose?
>

Hmm, the lower level remez simply takes a list of desired function values
and weights over a defined set of points in the transform domain, so in that
sense it is quite general as long as the desired frequency response is real.
It is a bit crippled at the moment, however, and only does
symmetric/antisymmetric filter designs whereas it could theoretically do
complex hermitean designs with a few small mods. I see that the sigtools
interface does do differentiators or passbands with specified gain and
relative ripple. I really don't see why it isn't in with the filter design
stuff where you would have noticed it. Maybe we need to submodules, one for
remez designs, the other for win designs, something like fir_windowed and
fir_equiripple.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090511/092b4079/attachment.html>