JuliaApproximation / JuliaApproximation/GenericFFT.jl
Type inconsistencies with FFTW?
Nobody has claimed this yet.
- Dominant language
- Julia
- Stars
- 16
- Forks
- 6
- PR merge metrics
- No merged PRs in 30d
Description
FFTW plans are <:AbstractFFTs.Plan{T} with T complex for complex-to-real plans and T real for real-to-complex plans. So the parametric type of the plan is the type of the input. However, the plans here always seem to be <:AbstractFFTs.Plan{Complex}. Is that on purpose?
julia> generic_plan = GenericFFT.plan_rfft(zeros(Float16,64))
GenericFFT.DummyrFFTPlan{ComplexF16, false, UnitRange{Int64}}(64, 1:1, #undef)
julia> fftw_plan = FFTW.plan_rfft(zeros(64))
FFTW real-to-complex plan for 64-element array of Float64
(rdft2-ct-dit/8
(hc2c-direct-8/28/1 "hc2cfdftv_8_avx2"
(rdft2-r2hc-direct-8 "r2cf_8")
(rdft2-r2hc01-direct-8 "r2cfII_8"))
(dft-direct-8-x4 "n2fv_8_avx2_128"))
julia> supertype(supertype(typeof(fftw_plan)))
AbstractFFTs.Plan{Float64}
julia> supertype(supertype(typeof(generic_plan)))
AbstractFFTs.Plan{ComplexF16} # expected Float16 not ComplexF16
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the examples using GenericFFT.plan_rfft and FFTW.plan_rfft, then inspect the resulting AbstractFFTs.Plan type parameters. The work is done when real-to-complex and complex-to-real plans report the same input-type parameter convention as FFTW without breaking the demonstrated plan construction.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia
- Domain
- data
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100