Hello, Is this behavior normal/expected or is it a bug (I just noticed it doesn’t happen for 2 dimensional arrays)? fff()=(u=rand(3,3,4);FFTW.fft(u)) @code_warntype optimize=:true fff() Variables #self#::Core.Compiler.Const(fff, false) u::Array{Float64,3} Body::Any 1 ─ %1 = invoke Random.rand…

Make the array complex maybe? julia> fff()=(u=rand(3,3,4);FFTW.fft(complex.(u))) fff (generic function with 1 method) julia> @code_warntype fff() Variables #self#::Core.Compiler.Const(fff, false) u::Array{Float64,3} Body::Array{Complex{Float64},3} 1 ─ (u = Main.rand(3, 3, 4)) │ %2 = FF…

The complex conversion allocates, needlessly. Something is off, as this is not needed in 2D: using FFTW,BenchmarkTools fff()=(u=rand(3,4);FFTW.fft(u)) @code_warntype optimize=:true fff() Variables #self#::Core.Compiler.Const(fff, false) u::Array{Float64,2} Body::Array{Complex{Float64},2} 1 ─ …

[image] raminammour: The complex conversion allocates This is what fft does under the hood anyway, you just don’t see it.

That I know, and it shows in the typed code in 2D. But the conversion to complex would allocate another array that is not used. Doing what FFT should be doing by hand, infers: fff2()=(u=rand(3,4,5);fu=complex(u);fft!(fu)) @code_warntype optimize=:true fff2() Variables #self#::Core.Compiler.Const(…

I think the problem is that AbstractFFTs.complexfloat is not type stable on a 3-d array, this is what is used to convert the real to the complex array: julia> @code_warntype AbstractFFTs.complexfloat(u) Variables #self#::Core.Compiler.Const(AbstractFFTs.complexfloat, false) x::Array{Float64,3} …

[image] giordano: AbstractFFTs.complexfloat(u) Which leads all the way to Base.circcopy! for the real source of the instability, still chasing it down…

My guess is more on the y = Array{T}(undef, map(length, axes(x))) line, the size of the y array, which is part of its type, can’t probably be inferred.

length isn’t part of array types. Only number of dimensions.

In fact I said size :slight_smile:

FFT(W) does not infer

General Usage

raminammour March 23, 2020, 6:22pm 12

I suspect the real culprit here to be circcopy!, see Circcopy! does not infer for 3D arrays.

Topic		Replies	Views
ANN: InplaceRealFFT.jl : inplace real-to-complex and complex-to-real FFT Numerics fftw	25	3506	January 5, 2018
`fft(v)` fails for subtypes of `AbstractArray{<:Complex}` General Usage fftw	2	584	January 9, 2019
Type stability around of wrapped plan fft General Usage question , fftw , type-stability	2	251	August 8, 2023
Allowed types for `fft()` and `ifft()` when using sparse arrays Numerics fftw , sparse	0	424	July 12, 2021
Comparison of different fft-implementations Signal and Image Processing fftw , signal-processing , fft	11	2298	October 7, 2022

FFT(W) does not infer

Related topics