I am currently working on some examples for pydwf that show how to use the FDwfSpectrum functionality implemented in the DWF library.
To make those examples I am thoroughly testing the three FDwfSpectrum functions, and I'm seeing several cases where I don't think the behavior is quite correct. I will detail my findings in this post and some followups, in the hope that the behavior observed will be considered for fixing, and for feedback.
Starting with the simplest function: FDwfSpectrumFFT.
First, the way the function returns its result (as separate phase and bin magnitude arrays, rather than real/imaginary components of the complex number results) is quite non-standard. No mainstream FFT implementation that I am aware of does this, and I've seen about a dozen.
Second, the scaling of the FFT (as returned in the bin magnitude vector) deviates from the convention that essentially all FFT implementations (except Mathematica) use nowadays; it is smaller by a factor (2 / n), where n is the length of the vector being FFT'ed. This unusual scaling choice is undocumented.
Third, the function gives an incorrect result of +infinity or -infinity when doing an FFT on a 1-element vector. One could argue that this is not an interesting case, but I see no reason why it shouldn't return the correct result. If this is a "won't fix", at least the documentation should indicate that the function only works correctly for n >= 2.
Lastly, the performance is quite bad compared to a properly optimized function like numpy's rfft function. The graph attached shows how much slower FDwfSpectrumFFT is compared to the numpy function, ranging from 2.5 to 20 times for different FFT sizes. The Numpy function also has the advantage of correctly handling input sizes that are not a power of two, unlike the FDwfSpectrumFFT function.
(My personal opinion is that the FDwfSpectrum functionality should have never made it into DWF, since (1) it simply has no place in an instrument-control library and constitutes a clear-cut example of feature bloat in an already huge library, and (2) dedicated, specialized signal processing libraries exist that handily outperform the FDwfSpectrum implementations. But that ship has sailed, I'm afraid.)
Question
Guest
Hi,
I am currently working on some examples for pydwf that show how to use the FDwfSpectrum functionality implemented in the DWF library.
To make those examples I am thoroughly testing the three FDwfSpectrum functions, and I'm seeing several cases where I don't think the behavior is quite correct. I will detail my findings in this post and some followups, in the hope that the behavior observed will be considered for fixing, and for feedback.
Starting with the simplest function: FDwfSpectrumFFT.
First, the way the function returns its result (as separate phase and bin magnitude arrays, rather than real/imaginary components of the complex number results) is quite non-standard. No mainstream FFT implementation that I am aware of does this, and I've seen about a dozen.
Second, the scaling of the FFT (as returned in the bin magnitude vector) deviates from the convention that essentially all FFT implementations (except Mathematica) use nowadays; it is smaller by a factor (2 / n), where n is the length of the vector being FFT'ed. This unusual scaling choice is undocumented.
Third, the function gives an incorrect result of +infinity or -infinity when doing an FFT on a 1-element vector. One could argue that this is not an interesting case, but I see no reason why it shouldn't return the correct result. If this is a "won't fix", at least the documentation should indicate that the function only works correctly for n >= 2.
Lastly, the performance is quite bad compared to a properly optimized function like numpy's rfft function. The graph attached shows how much slower FDwfSpectrumFFT is compared to the numpy function, ranging from 2.5 to 20 times for different FFT sizes. The Numpy function also has the advantage of correctly handling input sizes that are not a power of two, unlike the FDwfSpectrumFFT function.
(My personal opinion is that the FDwfSpectrum functionality should have never made it into DWF, since (1) it simply has no place in an instrument-control library and constitutes a clear-cut example of feature bloat in an already huge library, and (2) dedicated, specialized signal processing libraries exist that handily outperform the FDwfSpectrum implementations. But that ship has sailed, I'm afraid.)
Link to comment
Share on other sites
8 answers to this question
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now