Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FFT - DSP(Double)SplitComplex and conjugate symmetric #96

Open
ChristianSteffens opened this issue Feb 26, 2019 · 3 comments
Open

FFT - DSP(Double)SplitComplex and conjugate symmetric #96

ChristianSteffens opened this issue Feb 26, 2019 · 3 comments

Comments

@ChristianSteffens
Copy link

ChristianSteffens commented Feb 26, 2019

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:

  1. 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.

  1. 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).
@alejandro-isaza
Copy link
Collaborator

Not entirely sure how it came to be. Would you be willing to create a PR with your proposed changes?

@ChristianSteffens
Copy link
Author

ChristianSteffens commented Feb 26, 2019

Would you be willing to create a PR with your proposed changes?

We're currently validating an implementation using the packed FFT algorithm with several test-vectors against Matlab's FFT implementation. If this works out, I could certainly create a PR for this. I'll keep you updated.

Still, it would be worth knowing what you design decision was. I'm not a DSP expert and in fact only collected some thoughts from stackoverflow to get some kind of understanding of FFTs in general.

@alejandro-isaza
Copy link
Collaborator

Maybe @mattt can shed some light.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants