[SciPy-user] firwin upgrades

[Stéfan van der Walt]

Hi Tom

2009/5/2 Tom K. <tpk at kraussfamily.org>:
> 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?

The current signature is

s.firwin(N, cutoff, width=None, window='hamming')

In the suggested API (which is just that, since I haven't designed
filters in ages) the input is always an array/list, so what I would do
is to change the signature to

s.firwin(N, freqs, type='pass', width=None, window='hamming')

Whenever freqs is a scalar and type is 'pass', we have the old
behaviour (and API compatibility).  For other behaviour, the user has
to change type to 'stop', or has to specify an array of values in
freqs.

If you don't want the 'type' flag, it may be simpler to have two
separate functions

fir_pass and
fir_stop

that call firwin with the appropriate parameters.

> 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 ;-)

Good idea.  The scaling is necessary by default, so its best the user
manually switches it off if not required.

Is freqz working properly?  I'm trying to get a filter response out of
it, but the results look a bit strange.

Cheers
Stéfan