This is a self-answer to Is there a package for Sliding Discrete Fourier Transforms?
The package SlidingDFTs provides the tools to compute Sliding Discrete Fourer Transforms (SDFT) recursively, over one-dimensional series of values. The SDFT implemented in this package are different from spectrograms (e.g. as defined in DSP.jl) in various ways:
- They are lazy, non-indexable iterators that update the computed DFT at each iteration.
- The stride or step between consecutive DFTs is always one sample.
- The input data series are not limited to
AbstractArrays- they can even be stateful iterators!
This is meant to provide a significant improvement in performance with respect to repeated computation of FFTs. I haven’t done a systematic benchmark yet, but in real use cases I have observed a reduction of computation times over one order of magnitude.
Its usage is very simple: given a data series x, just do:
itr = sdft(SDFT(n), x)
and you will have an iterator that yields a Vector{Complex(eltype(x))} of length n at each iteration (the DFT of the first n values at the first iteration, from the second to the n+1-th value at the second iteration, etc.). Typically used in a loop:
for spectrum in sdft(SDFT(n), x)
# `spectrum` is a `Vector{Complex(eltype(x))}` of length `n`
end
For the time being, only the most basic version of the SDFT is implemented (the SDFT type used in the previous example). There are many possible variations (see for instance Chauhan and Singh’s paper cited in the linked post above), and the package provides an interface to facilitate the implementation of new methods, either as PRs to this one or in independent packages (see the docs). I plan to implement myself at least the rSDFT, but I’m happy to leave it to others if someone doesn’t want to wait for me.
I have not registered the package because I would like others to review it first and give suggestions about how to improve it (@roflmaostc kindly offered to do it in the old post). I’m not particularly fond of the names of structs and functions, so feel free to make suggestions about them too. Also about the general structure - e.g. is it ok to have the interface and the particular implementations in a single package because the code base is small, or would it be preferable to split it?, etc.
I’m also open to suggestions about maintenance. I’m not particularly interested in “owning” the package, since to be honest this is not a tool that I’ll be using that often. (It’s useful for a project I’m involved in right now, but once that project is over I may not use it anymore.) So, if this is worth to be integrated as part of another package, or transferred to an organization, instead of registering it as it is, I’ll be fine with that too.
