I'm currently evaluating several FFT implementations and I tried out your implementation (of the vDSP algorithm collection). After some reading there're two things I don't fully understand and I hope you might help us out here:
- Is there a reason you're not using
vDSP_fft_zrip / vDSP_fft_zripD? I understand that your implementation works with real input vectors. So what's the benefit of not (!) using the "packed" implementation with the 'r' in the middle of the function name. The 'packed' implementation needs some additional packing / unpacking - but that's it.
I'm specifically referring to the statement in https://github.com/jseales/numpy-style-fft-in-obj-c
The little 'r' somewhere in the middle of the function name is what designates it as the special fft designed to work with the packed up array. "vDSP_fft_zipD" with no 'r' is the complex version, and is easier to use because there are no packing and unpacking steps, but not as efficient, beautiful, or clever.
Certainly your implementation works, but it seems using the different method it should run faster or at least more efficient? On that note it's worth exploring the "in-place" variants of the methods as well.
- Your implementation calculates the (normalized) magnitudes of all input values. But from my understanding of the so called
conjugate symmetric fft "half of the result" could be discarded anyhow (for real input values).
I'm currently evaluating several FFT implementations and I tried out your implementation (of the vDSP algorithm collection). After some reading there're two things I don't fully understand and I hope you might help us out here:
vDSP_fft_zrip/vDSP_fft_zripD? I understand that your implementation works with real input vectors. So what's the benefit of not (!) using the "packed" implementation with the 'r' in the middle of the function name. The 'packed' implementation needs some additional packing / unpacking - but that's it.I'm specifically referring to the statement in https://github.com/jseales/numpy-style-fft-in-obj-c
Certainly your implementation works, but it seems using the different method it should run faster or at least more efficient? On that note it's worth exploring the "in-place" variants of the methods as well.
conjugate symmetric fft"half of the result" could be discarded anyhow (for real input values).