On Sun, Aug 6, 2017 at 1:10 PM, Phillip Feldman <phillip.m.feldman@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@python.org https://mail.python.org/mailman/listinfo/scipy-dev