Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Sliding Discrete Fourier Transforms #49

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

heliosdrm
Copy link

Following the recommendation in: https://discourse.julialang.org/t/ann-announcing-slidingdfts-jl/123793

This is an adaptation of https://github.com/heliosdrm/SlidingDFTs.jl for FourierTools. Some points to note:

  • This PR actually contains two things: an interface to use and develop SDFTs, and the actual implementation of SDFT methods. Accordingly, two files are included in src: sdft_interface.jl (with a module SlidingDFTs), and sdft_implementations.jl. The documentation page deals with both of them in different sections.
  • Only the most basic method is implemented for the time being. At least the rSDFT will follow if this is approved.

@heliosdrm
Copy link
Author

There may be details of this implementation that require an explanation. Please ask as needed.

To start with, one might ask about the design of SlidingDFTs.dataoffsets. It is meant to return the offsets that can be used in the calls to SlidingDFTs.previousdata for a given SDFT method, but in reality the only that matters is whether it returns nothing or anything else. So why?

The answer is that the whole design of the interface to create SDFT methods was devised before implementing it, and at that time I planned two different kinds of SDFT implementations:

  1. One suitable for input data that are stateful iterators (the one that is currently coded). The states of SDFT iterators store an array with all previous values of the input data that may be used in future iterations: for the i-th iteration of the SDFT, this is the input data samples from its i-th position to its i+n-th position, where n = SlidingDFTs.windowlength(method).

  2. Another that would store less data, but would not be suitable for stateful iterators. Instead of the full fragment of the input between i and i+n, it might store a smaller set of data based on the output of SlidingDFTs.dataoffsets, namely either:

  • a collection of states of the input iterator, corresponding to its positions at (i+j for j in SlidingDFTs.dataoffsets(method)),
  • or the fragment of data values from i to i+m where m = maximum(SlidingDFTs.dataoffsets(method)), plus the state at i+m - in order to update that fragment at the next iteration.

However, when I tried to implement that, I found no improvement in performance or memory allocations for the second kind of SDFTs, so I decided to keep it simple, and leave only the first kind, which works for both stateful and stateless input iterators. But I didn't change the interface, since I don't rule out the possibility of finding a smarter algorithm for stateless iterators, using the minimum amount of data about past data samples.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant