[SciPy-Dev] SciPy roadmap does not address limitations of current filter-related code

[Warren Weckesser]

On Sun, Aug 6, 2017 at 1:10 PM, Phillip Feldman <phillip.m.feldman at gmail.com
> wrote:

> Some of us in the engineering community are unhappy with the SciPy
> roadmap. From our perspective, the main deficiency of scipy.signal is that
> the filtering functionality is of limited practical utility. We would like
> to see the following:
>
> (1) support for lowpass, bandpass, and bandstop FIR filter design, with
> the user specifying (a) the passband ripple, (b) the minimum stopband
> rejection, and (c) the design method, with this last being optional. Rather
> than forcing the user to specify the order of the filter, which requires
> many iterations to determine the minimum filter order that will do the job,
> we'd like to see the code automatically determine the minimum filter order
> that can meet the user's specs.
>
> (2) support for fixed-binary-point arithmetic.
>
> (3) support for filtering and the design of filters that use
> fixed-binary-point arithmetic.
>
> Such changes would be a big step in the direction of making
> Python+NumPy+SciPy a viable alternative to Matlab + the Matlab Signal
> Processing Toolbox.
>
>


Hi Phillip,

Thanks for the feedback.  Those are all great suggestions, and would be
valuable additions to SciPy.

My comments in this somewhat long response are my own opinions and not
necessarily those of any other SciPy developers.

The first request, for a method to design a FIR filter (including the
determination of the order of the filter) given the desired passband ripple
and stopband rejection, can be done with the existing tools in SciPy, if
you don't mind a small amount of "brute force" search.  I have some code
that works reasonably well for lowpass, highpass, bandpass and bandstop FIR
filters.  I'll make this available soon, but I don't know if it will end up
in SciPy itself.

Filtering with fixed-binary-point arithmetic is an important topic, but I
don't know if any of the folks currently working on SciPy have experience
in this area.  So I don't see it happening in the immediate future.  On the
other hand, there are several sharp folks contributing to the 'signal'
package these days, and maybe one or more of them will be interested in
tackling such a project.

Now I have to give what is basically the boilerplate response that anyone
who helps maintain a free, open source software project would give--I'm
sure you've heard it before:  SciPy is developed and maintained by
volunteers.  We all have our areas of interest and expertise, and we all
have our areas of ignorance.  If we can get more people with more diverse
backgrounds involved with SciPy development, we can improve the library
that much faster.  "Involved" doesn't necessarily mean writing code--there
are several ways for you and your colleagues in the engineering community
to contribute.

You've already contributed using one the simplest methods: create bug
reports and requests for enhancements.  Let us know what you need.  The
more information that you can provide in these reports, the better.  In
some cases, you may have to educate the SciPy developers.  This can include:

   a. Describe algorithms that you know work well.  Provide links
      to published papers or relevant textbooks where the algorithm
      is described.
   b. Find existing open source implementations that might serve as
      a basis for the SciPy implementation.  (Avoid, however, software
      that is GPL licensed. SciPy will not include software that is
      derived from GPL software.)  For example, in a response to your
      email, Dan White pointed out pyFDA.  If you have a chance to try
      it, let us know if the content looks suitable for adding to SciPy.

Also, if a feature request or bug fix that you need is already under
discussion in a github issue or pull request, please feel free to join the
discussion.

Of course, you can also contribute code.  If SciPy is missing a feature
that you and your colleagues need, then why not get together, create an
implementation, and add it to SciPy via a pull request?  Just be prepared
for the iterative code review process, in which the SciPy developers become
familiar with the code in the pull request and also ensure that the code
conforms to the SciPy style, documentation and testing standards.  Major
enhancements should be discussed first on the mailing list.  More details
are in https://github.com/scipy/scipy/blob/master/HACKING.rst.txt.

I'll reply to your question about kaiserord() in a separate email.

Best regards,

Warren






> As an aside, I'd like to comment on the documentation for
> `scipy.signal.kaiserord`, which says the following:
>
> scipy.signal.kaiserord(ripple, width)[source]
>
> <snip> ripple : float
>
> Positive number specifying maximum ripple in passband (dB) and minimum
> ripple in stopband.
>
> When designing a lowpass digital filter, one normally specifies the
> maximum ripple in the passband and the minimum rejection in the stopband.
> With this function, there is no way to specify how much rejection one gets
> in the stopband, and the filter design code is also apparently trying to
> limit stopband ripple, which is something that no engineer would care
> about. The documentation can't just be badly worded, because there would
> have to be another parameter to specify the stopband rejection.
>
> Phillip
> --
> Dr. Phillip M. Feldman
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20170811/76178798/attachment.html>