Strided output

[maximilian-gelbrecht]

Looking into the code, there seems to be some low-level support for strided output, as e.g. shown by the ostride property all plans have. However, either I am overlooking this or there doesn't seem to be any support for this on a higher level for the user. In all of the plans there's no option to set the output array (or its strides), the plan_f functions just automatically generate a FakeArray with the correct output size to hand over to the low-level constructor as an output array from with the ostride is then inferred.

Is there some problem that makes strided output difficult or is the user interface for that just not implemented?

[maximilian-gelbrecht]

Defining

for (Tr,Tc) in ((:Float32,:(Complex{Float32})),(:Float64,:(Complex{Float64})))
    # Note: use $FORWARD and $BACKWARD below because of issue #9775
    @eval begin
        function plan_rfft_with_stride(X::StridedArray{$Tr,N}, region;
                           flags::Integer=FFTW.ESTIMATE,
                           timelimit::Real=FFTW.NO_TIMELIMIT,
                           num_threads::Union{Nothing, Integer} = nothing,
                           ostride=Tuple(1 for i in 1:N)) where N
            if num_threads !== nothing
                plan = set_num_threads(num_threads) do
                    plan_rfft_with_stride(X, region; flags = flags, timelimit = timelimit)
                end
                return plan
            end
            osize = FFTW.rfft_output_size(X, region)
            Y = flags&FFTW.ESTIMATE != 0 ? FFTW.FakeArray{$Tc, N}(osize, ostride) : Array{$Tc}(undef, osize)
            FFTW.rFFTWPlan{$Tr,$FFTW.FORWARD,false,N}(X, Y, region, flags, timelimit)
        end
    end 
end 

does work. Any objections to a PR implementing that?

[stevengj]

The right way do do this is to plan an FFT for a view, since a view contains strides, and then call the plan in-place on that view using mul!(output, plan, input).

Unfortunately, there is currently no planner API that lets you specify the output array — we should just have a method plan_fft!(output, input, ...) for this.

[maximilian-gelbrecht]

The right way do do this is to plan an FFT for a view, since a view contains strides, and then call the plan in-place on that view using mul!(output, plan, input).

That's exactly what I am doing in my actual use case of this.

Unfortunately, there is currently no planner API that lets you specify the output array — we should just have a method plan_fft!(output, input, ...) for this.

Sure, that's a bit more intuitive than specifying the output stride directly, but the logic isn't really different, right? All plans take in the output array as Y in a low level, so this would just mean a fairly minor change compared to the plans that exist, or are there any problems with that that I don't see at the moment?

[stevengj]

I agree that it should be a fairly minor change.