Is it time to make a pure Julia FFT?

While FFTW is great, it is a GPL-licensed C library. R, Mathematica, Python’s Scipy, etc have their own FFT library. Should we finally have our own FFT library? A pure Julia FFT may provide several advantages such as being extensible via the Julia compiler extensions, operating on different array types, etc. Implementing FFT also comes with the benefit of putting Julia’s ecosystem to the test.

5 Likes

I have made one for the use of myself.

3 Likes

Are you proposing to write this yourself?

2 Likes

I might as well at some point if I’m done with my current project. There are many algorithms out there and developing the best approach will take time. I’ve written FFT in C++ before. Writing a fast FFT, however, is complicated. Maybe I will create and participate in a fun contest.

Good idea, maybe I’ll learn much more about FFT with it.

The fastest FFT approach I’m aware of is Spiral.

2 Likes
8 Likes

I know that one.

There is FFTA.jl: Fastest Fourier Transform in my Apartment
It’s pure julia.

23 Likes

Nice name.

8 Likes

I would like to have a FFT.jl package in pure Julia with detailed documentation . :heart_eyes:

2 Likes

There is also this quite old pure Julia FFT PR from @stevengj

1 Like

FFFTW is great, if you’re of with GPL and its size. You have some good points for pure Julia, but for most wrapping an existing library is likely best as a JLL (if you can do away with Float64, Float32 types, I didn’t check if it has Float16):

2 Likes

Okay, Julia actually has a binding for RustFFT that is both faster than FFTW and is permissively licensed. That is good enough for me. As for the pure Julia FFT, that would remain an interesting idea for anyone to try, but I’ll leave that to the experts.

3 Likes

It might worth to look at PhastFT.
There was a thread on Hacker News: Fast Fourier Transform in Rust.

2 Likes

It might be a good library, and you can already use it from Python, because of PyO3, and thus from Julia with PythonCall.jl.

But I’m thinking, Like with C++, it’s hard or impossible to wrap Rust code, i.e. it has to allow it, make a C API. Or so I though, but I see that [pyfunction] (and that trivially small file), is it only supporting Python easily, not all other languages? So to make the question more general, should Julia make it easier to support PyO3 Rust projects, ie. could it support the Python API directly, i.e. without PythonCall (although it’s not a terribly large, or problematic, dependency), or a wrapper depending on it? Some such R[Py3]Call.jl specifically for that?

2 Likes