Henrik Enquist

I can just mention that the RealFFT crate is now updated to use RustFFT 5.0.

The main thing I dislike with the inplace solutions is that they all offer very poor ergonomics since they need to store complex values in a real vector. The advantages...

Have you looked at the RealFFT crate? At 4096 the fft should be about twice as fast, and you can skip the conversion to complex.

I on the other hand definitely prefer the half-complex format. My main use case is processing of audio data, doing stuff like convolution. Then I have a real valued signal,...

Doing convolution that way only works when both the signals are real. Then they both have zeros in those places of their transforms, and the zeros stay also after element-wise...

I think only forward R2C and inverse C2R are useful in practice. I have never seen the other two (fftw doesn't have them for example) and I can't think of...

This explains a lot, thanks! I'm guessing a DHT would not be able to directly reuse very much of the code in RustFFT(?). Then it makes more sense to put...

Yes the convenience itself makes it worth having it. Are you adding this in RustFFT now-ish? If yes I won't do anything more to RealFFT, just mark it as deprecated...

From what I can tell, it's using the same trick as us: [https://github.com/linkotec/ffts/blob/2c8da4877588e288ff4cd550f14bec2dc7bf668c/src/ffts_real.c#L407](https://github.com/linkotec/ffts/blob/2c8da4877588e288ff4cd550f14bec2dc7bf668c/src/ffts_real.c#L407) I don't see anything that would help with odd length real ffts. The documentation of FFTS is...

I made a big rewrite of RealFFT: https://github.com/HEnquist/realfft/pull/7 It now behaves a lot more like RustFFT, with a planner that reuses ffts. And whenever it makes sense it uses the...