Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complex-float logic needs to be replicated by plans #87

Open
gaurav-arya opened this issue Mar 11, 2023 · 0 comments
Open

Complex-float logic needs to be replicated by plans #87

gaurav-arya opened this issue Mar 11, 2023 · 0 comments

Comments

@gaurav-arya
Copy link
Contributor

gaurav-arya commented Mar 11, 2023

The current design of AbstractFFTs.jl requires plan implementers to handle the complex-float promotion when doing *(p::MyPlan, x), e.g. as done below in the test plans here:

Base.:*(p::TestPlan, x::AbstractArray) = mul!(similar(x, complex(float(eltype(x)))), p, x)

This would ideally be taken care of AbstractFFTs.jl just like is done for fft etc.

Edit (July 29): possibly, the right way to solve problems like this (and other ones like having to manually compute normalization in plan_inv), would be a trait. The AdjointStyle trait was recently added, whose scope was limited to enabling adjoint functionality given that inverse functionality for the plan already exists. We could add additional traits for automatically getting other functionality that is the same for e.g. all FFTs (and even parent traits that specify all additional traits together) such that downstream implementers have to implement the minimum possible functionality when the right trait exists

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant