Extension of `AbstractFFT`

[DylanMMarques]

Hi,

I was wondering if there would be interest in having a extension of DimensionalData for AbstractFFT with the aim of using the additional information providing by the lookups.

My idea would be something like this:

function fft(dd::AbstractDimVector)
     dx = step(lookup(dd, 1))
     fx = fftfreq(length(dd), 1 / dx)
     fft_dd = fft(parent(dd))
     D = DimensionalData.basetypeof(dims(dd, 1))
     fft_dd .*= dx
     DimVector(fft_dd, D(fx))
end

 fft(rand(X(1:100)))
┌ 100-element DimArray{ComplexF64, 1} ┐
├─────────────────────────────────────┴─────────────────────── dims ┐
  ↓ X Sampled{Float64} [0.0, …, -0.01] Unordered Irregular Points
└───────────────────────────────────────────────────────────────────┘
 ⋮      ⋱  

Ideally, the implementation would support fft_plan, mul! and N-dimensional arrays.

Happy to create a PR if there is interest in adding something like this as an extension.

[rafaqz]

Sounds great. Does it also makes sense for 2d ffts?

[DylanMMarques]

I think it makes sense for any number of dimensions.

[rafaqz]

Some questions: (I think solvable but will need to be addressed)

• What about Irregular lookup spans ( where step won't work)?
• what happens with Intervals vs Points?
• For multiple dimensions, what happens when one dimension is Float64 and the other holds a DateTime lookup? Or they have different Unitfil.jl units?

[DylanMMarques]

• What about Irregular lookup spans ( where step won't work)?
  In my opinion, an error should throw in this case. FFT assume a uniform sampling so I would say that fft of a dimensional array with irregular lookup is not correct.

• what happens with Intervals vs Points?
  I assume that with Intervals you mean this case:

     DimVector(rand(10), X(intervals(1:10)))

I think this case might be tricky. A implementation that ensures correctness would need to check that the width of the interval is constant and that the boundaries of each interval contact with the next interval.
I think that, for the first version, all cases that the lookup is not <:AbstractRange should throw an error. We can then improve later, as adding automatic checking if doing the fft of a specific DimArray makes sense or not.

• For multiple dimensions, what happens when one dimension is Float64 and the other holds a DateTime lookup? Or they have different Unitfil.jl units?
  For multiple dimensions, fftfreq would need to be called for each dimension. Something like (code not tested):

function fft(dd::AbstractDimArray{N}) where N
    steps_dd = ntuple(i -> step(lookup(dd, i)), N)
    freqs = ntuple(i -> fftfreq(size(dd, i), 1 / steps_dd[i]), N)
    fft_dd = fft(parent(dd))
    lookups = ntuple(i -> basetypeof(dims(dd, i))(freqs[i]), N)
    fft_dd .*= prod(steps_dd)
    DimArray(fft_dd, lookups)
end

The fftfreq part should work fine with Unitful with the code above. However, it would need some extra work to reinterpret the array as prod(steps_dd) would have a unit rendering throwing a error in this step fft_dd .*= prod(steps_dd). For this part, an extension of both AbstractFFT & Unitful might be needed as the code will need access to the units information.
The case of DateTime might need to throw an error for now. The reason being that the inverse Month does not exist.

[rafaqz]

Ok. We have a span trait for regular space lookups - Regular, as a Vector can also be regular, not just AbstractRange.

Limiting to Regular is reasonable, and will work for both Ponts and Intervals. Although, you may want the intervals to always have values at their Center position? Often they are for the Start of the interval. shiftlocus can fix that for you.

Units may be workable without Unitful.jl

[DylanMMarques]

Thanks, make it work with Regular makes sense.

I will have a think about Intervals. Depending on where the interval is centred it might need a phase correction on the fft. But I am not sure if users would be expending that correction to be applied or not.

I will try to see if I manage to make it work without Unitful.jl

[felixcremer]

Is this closed with #1044 or is there still something left to work on?