[RFC]: signal process related algorithms like fft family

[congzhangzh]

Description

This RFC proposes

Add supports for signal processing api like multidirectional fft/ifft/fftshift/ifftshift

Tks,
Cong

Related Issues

Related issues # , # , and # .

Questions

No.

Other

No.

Checklist

• I have read and understood the Code of Conduct.
• Searched for existing issues and pull requests.
• The issue name begins with RFC:.

[stdlib-bot]

👋 Hi there! 👋

And thank you for opening your first issue! We will get back to you shortly. 🏃 💨

[kgryte]

@congzhangzh Yes, this is definitely desired. We've done a little bit of R&D here, and have FFT support currently listed as a potential Google Summer of Code project (see stdlib-js/google-summer-of-code#3); however, we would be open to exploring support outside of GSoC, provided there was a motivated contributor.

[congzhangzh]

I find one, although it’s very old:)

https://github.com/corbanbrook/dsp.js

[AyushkhatiDev]

@congzhangzh @kgryte Thanks for the insights! It’s great to know that FFT support is already being considered for GSoC. I'm definitely interested in contributing to this, even outside of GSoC, and I’m happy to help advance this feature.

I’ll take a closer look at the existing dsp.js library to understand how its signal processing functions work and see how we can extend them to implement multidirectional FFT, IFFT, and the associated shift operations. Once I have a clearer understanding, I’ll start working on integrating these features.

[kgryte]

As linked to in the GSoC idea issue, we are much more likely to accept FFT support which effectively ports PocketFFT to stdlib. This will involve implementations in both C and JavaScript. Most, if not all, existing JavaScript implementations are not particularly robust.

As with our current BLAS interfaces, we should look into whether we can create something which is backend agnostic, so that a user can specify to use, e.g., FFTW for accelerated performance on supporting platforms. This would be similar to how a user can specify to use, e.g., OpenBLAS or Apple Accelerate when compiling BLAS.

[AyushkhatiDev]

@kgryte Thank you for the detailed guidance! I understand that the preference is to port PocketFFT into stdlib, ensuring a robust implementation with backend agnostic support for libraries like FFTW. I’ll start by diving deeper into PocketFFT’s design and functionality to plan the porting process.

I’ll also review how stdlib currently integrates with other libraries, such as BLAS, to ensure the FFT API aligns with the existing standards. Once I’ve explored these aspects, I’ll outline my approach for implementing the multidirectional FFT and backend-agnostic interface and share it here for further feedback before proceeding. Let me know if there are any additional pointers to consider before I start.