FFT 和逆 FFT 之间有什么实际区别吗？
FFT 库（例如 FFTW 或 numpy.fft）通常提供两个函数 fft() 和 ifft()（及其用于实值输入的特殊版本）。这些函数的定义似乎是这样的：
ifft(fft(X)) == X
在对复杂输入进行操作的 ifft() 和 fft() 之间进行选择时，是否
fft(X) == constant_factor * reverse(ifft(X))
有任何实际或技术原因需要考虑？虽然 X（信号、时间或空间域）和 fft(X)（频谱、频域）的解释不同，但它在计算上重要吗？
FFT libraries such as FFTW or numpy.fft typically provide two functions fft() and ifft() (and special versions thereof for real valued input). Those functions appear to be defined such that
ifft(fft(X)) == X
and
fft(X) == constant_factor * reverse(ifft(X))
Are there any practical or technical reasons to consider when choosing between ifft() and fft() operating on complex input? While the interpretations of X (signal, time or space domain) and fft(X) (spectrum, frequency domain) are different, does it ever matter computationally?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不同的 fft 库将缩放常数放在不同的位置，在 fft、ifft 或两者中的 1/sqrt(N) 中。所以这只是一个很小的依赖于实现的差异。 fft 和 ifft 颠倒其结果的顺序。因此，这只是结果数组中向前或向后索引之间的区别。无论您将时间/空间称为时间/空间还是频率，都只是标签上的差异。
因此，实际上，选择一个无论库使用什么规模以及您想要索引结果的方向都会产生最具可读性的代码的库。通常，fft/ifft 库的设置是为了可以在同一方向 (++) 索引正时间和更高频率。
添加：次要的、可能不必要的优化：如果您无论如何都需要对 FT 结果进行后缩放，则选择不包含内置缩放乘法的 fft 或 ifft 实现，因为这可能会节省 N 个半冗余乘法运算。
Different fft libraries put the scaling constant in different places, in the fft, ifft or 1/sqrt(N) in both. So that's only a minor implementation dependent difference. The fft and the ifft reverse the order of their results. So that's only a difference between indexing forwards or backwards in you result array. Whether you call one time/space versus frequency is only a labeling difference.
So practically, pick the one where whatever scale the library uses and the direction you want to index your results produces the most readable code. Usually the fft/ifft libraries are set up so that one can index positive time and higher frequency in the same direction (++).
ADDED: Minor, probably unnecessary optimization: if you need to post-scale the FT results anyway, then pick the fft or ifft implementation that doesn't include a built-in scale multiply, as this may save N semi-redundant multiply operations.