juliadsp / fouriertransforms.jl Goto Github PK

Thanks for the effort towards a pure-Julia fft package. I'm very interested in type-flexible fft, which I thought would be supported with such an fft implementation. However, Float16 is promoted to Float32

julia> x = rand(Float16,4);
julia> FourierTransforms.fft(x)
4-element Array{Complex{Float32},1}:
  2.2734375f0 + 0.0f0im       
 -0.6142578f0 + 0.38378906f0im
 -0.5371094f0 + 0.0f0im       
 -0.6142578f0 - 0.38378906f0im

and arbitrary number formats are not supported

julia> using SoftPosit
julia> x = Posit16.(rand(4))
4-element Array{Posit16,1}:
     Posit16(0x3e4e)
     Posit16(0x0eb6)
     Posit16(0x10d8)    
     Posit16(0x308f)    
julia> FourierTransforms.fft(x)
ERROR: type Posit16 not supported
Stacktrace: ...

Can I contribute somehow to make this package fully type-flexible?

Some of the code for code generations is quite old a, I believe, predates generated functions. It would probably be a good idea to go though the code and see if some of the definitions would be cleaner with generated functions.

This package still uses the A_mul_B functions that got removed for 1.0. These should be updated to the new conventions.

Hello,

I was trying this package and I noticed that Double64 type provided by DoubleFloats is not supported. Is there a plan to add support for this in the future?

Best regards

I suspect I'm doing something extremely stupid, but I can't figure it out, so I figured I'd open this issue and maybe somebody who knows more about FFTs can help me figure this out. I'm trying to extend this package to FFTs over some finite field 𝔽 (in finite fields, FFTs are also known as the number-theoretic transform NTT). Everything seems to basically go through if I just generalize the Complex cases (code in gist: https://gist.github.com/Keno/51bcc385baed55120e9ed6111c541cba), but the output comes out permuted when compared to the naive summation:

julia> FourierTransforms.CTPlan(𝔽₁₇, true, 8) * 𝔽₁₇[0:7...]
8-element Array{𝔽₁₇,1}:
 11
  1
 14
  8
 13
  6
 12
  3

julia> _ntt(ω, v) = [sum((v[j]*ω^(j*i)) for j in eachindex(v)) for i in eachindex(v)]

julia> collect(_ntt(𝔽₁₇(9), OffsetArray(x, 0:7)))
8-element Array{𝔽₁₇,1}:
 11
  1
 12
  3
 13
  6
 14
  8

(note that the last three pairs of numbers are reversed). Unfortunately, I can't reproduce this with Complex, so I'm thinking I'm doing something very stupid, but I've wasted several hours on this and been unable to figure it out.

@stevengj as the resident FFT expert and original author of this code, any immediate things that would cause such a problem?
@andreasnoack any ideas?

The code in here assumes it's passed a canonically-indexed array, but accepts any AbstractArray (and then accesses it out of bounds with @inbounds set).

x = OffsetArray(Complex{FourierTransforms.Float64}[1.0, 2.0], 0:1)
julia> FourierTransforms.plan_fft(x)*x
2-element OffsetArray(::Array{Complex{Float64},1}, 0:1) with eltype Complex{Float64} with indices 0:1:
 2.300566222e-314 + 2.3005662377e-314im
              2.0 + 2.2317219686e-314im

The fft functions in AbstractFFTs do transform the index space, but as shown above the plan interface gives garbage on OffsetArray.

When testing this package against FFTW.jl I noticed certain inconsistencies depending on the floating point type and the array size.

To reproduce

import FFTW
import FourierTransforms

# (1) Size 8
data = randn(Float64, 8) .+ 0im
diff = maximum(abs, FFTW.fft(data) - FourierTransforms.fft(Complex{BigFloat}.(data)))
@assert diff < 1e-14  # Works fine

# (2) Size 9, standard floating point types
data = randn(Float64, 9) .+ 0im
diff = maximum(abs, FFTW.fft(data) - FourierTransforms.fft(Complex{Float32}.(data)))
@assert diff < 1e-5  # Works fine

# (3) Size 9, non-standard floating point types
diff = maximum(abs, FFTW.fft(data) - FourierTransforms.fft(Complex{BigFloat}.(data)))
@assert diff < 1e-14  # diff is about 8

Nine is the first array size which behaves as such. Arrays of sizes 1 to 8 are fine. Using other non-standard floating point types (e.g. DoubleFloats) seem to behave like in case (3) with roughly agreeing errors for what I checked, so it's not just BigFloat. Other problematic array sizes in the range 1 to 30 are 15, 18, 21, 25, 27, 30 ... I'd say that points to an issue related to the kernels for primes 3 and 5, but I have not checked so far.

In DFTK we are currently using this package for pursuing an implementation completely generic in the floating-point type. We are aware of the fact that this package is still in a very early state of development, but we would still like to depend on it for our development and releases. For this having this package registered in General or another registry would be very helpful. Is there any chance, this could happen soon?

We currently run our own registry (MolSim) for DFTK and a bunch of other packages for molecular science simulations and we would be happy to include FourierTransforms in form of a preview release until the authors consider it mature.

Are there any plans to register this package in the General registry? I'm playing around with some homomorphic encryption stuff, and it would be convenient if FourierTransforms.jl were in the General registry.

cc: @Keno