SciPy roadmap does not address limitations of current filter-related code
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. 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
Phillip Feldman kirjoitti 06.08.2017 klo 19:10:
Some of us in the engineering community are unhappy with the SciPy roadmap.
The roadmap is an open document, and suggestions for additions are very useful. It should not be considered as a finalized view of what is to came. In addition to opening mailing list discussions, you can also change the text directly by opening a pull request on github. [clip]
As an aside, I'd like to comment on the documentation for `scipy.signal.kaiserord`, which says the following:
For bug reports, filing an issue ticket on github is a somewhat better way as it ensures your comments will not be lost. -- Pauli Virtanen
Phillip, pyFDA is a project that builds off of scipy.signal and is similar to Matlab's filter design toolbox. https://github.com/chipmuenk/pyFDA A stated goal is working towards fixed-point capability and has the beginnings of HDL generation via myHDL. Dan
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
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.
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, It looks like the explanation of the 'ripple' argument of the function 'kaiserord' needs some work. You may be familiar with the following, but for anyone else following along, here's a summary of 'kaiserord'. The function 'kaiserord' implements the empirical FIR filter design formulas developed by Kaiser in the late 60's and early 70's. The reference that I have handy is Sections 7.5.3 and 7.6 of the text "Discrete-Time Signal Processing" (3rd ed.) by Oppenheim and Schafer. It is true that in this method, there is only one parameter that controls the passband ripple *and* the stopband rejection. Let delta be the attenuation (not in dB) in the stop band. In the Kaiser method, delta also determines the ripple of the gain in the pass band: it varies between 1-delta and 1+delta. The stop band rejection in dB is A = -20*log10(delta). This value (in dB) is the first argument of 'kaiserord'. Kaiser developed an expression for beta, the Kaiser window parameter, that depends on A, and also a formula for the filter order M in terms of A and w, where w is the transition width between the pass and stop bands. The Kaiser window design method, then, is to determine the order M and Kaiser window parameter beta using Kaiser's formula (implemented in `scipy.signal.kaiserord`), and then design the filter using the window method with a Kaiser window (using, for example, `scipy.signal.firwin`): numtaps, beta = kaiserord(A, w) taps = firwin(numtaps, cutoff, window=('kaiser', beta), [other args as needed]) Adding a good example to the docstring of 'kaiserord()' is on the SciPy to-do list (https://github.com/scipy/scipy/issues/7168). In the meantime, I have attached a self-contained script that demonstrates the Kaiser method for a lowpass filter. It generates the attached plot. Best regards, Warren
Phillip -- Dr. Phillip M. Feldman
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
participants (4)
-
Dan White -
Pauli Virtanen -
Phillip Feldman -
Warren Weckesser