Taaitaaiger
Support real-input FFTs and DCTs
realfft and RustDCT exist, it would be nice to use them to add support for these transformations.
Since realfft is just a wrapper of RustFFT for convenient FFTs of real-valued data, I wonder if it would be the easiest to just re-implement https://github.com/HEnquist/realfft/blob/master/src/lib.rs in Julia. This would also have the advantage that RustFFT.jl would not require building and depending on compatibility, updates, etc. of two Rust libraries.
RustDCT also uses RustFFT but it's a much larger and more complex package, it seems, so I guess there the easiest would be to actually use the Rust library.
I personally prefer adding the crate to the dependencies over reimplementing its functionality, even if it's a thin wrapper. Build time is not that important imo because the library is built in advance and distributed as a JLL, and I think it's likely that the API of rustfft and realfft will stay similar (but that's just my gut feeling).
Op do 21 sep. 2023 09:44 schreef David Widmann @.***>:
Since realfft is just a wrapper of RustFFT for convenient FFTs of real-valued data, I wonder if it would be the easiest to just re-implement https://github.com/HEnquist/realfft/blob/master/src/lib.rs in Julia. This would also have the advantage that RustFFT.jl would not require building and depending on compatibility, updates, etc. of two Rust libraries.
RustDCT also uses RustFFT but it's a much larger and more complex package, it seems, so I guess there the easiest would be to actually use the Rust library.
— Reply to this email directly, view it on GitHub https://github.com/Taaitaaiger/RustFFT.jl/issues/6#issuecomment-1729030841, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOQBHH2G54BDGRYV7TVZ3F3X3PV6FANCNFSM6AAAAAA3FFMXKA . You are receiving this because you authored the thread.Message ID: @.***>
It's a tradeoff, of course, but given that the wrapper is very small (https://github.com/HEnquist/realfft/blob/master/src/lib.rs contains also tests and docs) I assume it could be a reasonable alternative to implement the wrapper in Julia. It seems like a quite straightforward task with a well-defined scope; on the other hand, depending on another package/library means one has to keep up with the upstream updates and API changes and deal with the compilation process and its updates on Yggdrasil. Writing the Julia code should be more or less a one-time effort whereas wrapping realfft requires continuous maintenance.
Using realfft has two advantages, imo.
- It has already been implemented and tested.
- The twiddle factors are cached by the planner.
Overall I think the maintenance burden isn't that bad. The most recent backwards-incompatible release was a year ago, there's one issue that proposes a backwards-incompatible change but the authors of the crate have decided to wait until the next major version bump (by which I expect they mean RustFFT itself).
You're right that the implementation itself is pretty straightforward, I don't think it's unreasonable to add both implementations as separate plans.