-
Notifications
You must be signed in to change notification settings - Fork 34
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
Separate types for rFFT and FFT plans (and issues with ScaledPlans) #63
Comments
Based on discussion with @stevengj, an alternate solution would be to define However, on second thought I'm unsure whether there is any benefit to avoiding modifying the type hierarchy as @maximilian-gelbrecht suggested? That should not be any more breaking, because nothing would dispatch on the new abstract types except the rrule's, and those require some downstream changes in any case. And it seems to make things a lot simpler, unless there is some reason why the implementation of |
The reason to implement (And I would just implement methods for |
That makes sense -- then it seems there are two options:
In both cases, the |
The only problem with the abstract-plan approach is similar to what I commented in #56 — do we want to specify FFTW's choices for r2r transformations here? |
Hey, I made a draft PR here: #67 |
I opened #65 a while ago to fix this issue. |
Since PR #58 is now merged, I would suggest talking about how to extend this to
Plans
as well.One way of doing that would be to implement different (abstract) types for a FFT, rFFT and r2r. This of course would have some implications for the libraries relying on AbstractFFTs. That's why I did not directly proceed with a PR, but would want to discuss this first.
Something reasonable could be to have an
AbstractFFTPlan
,AbstractrFFTPlan
,AbstractR2RPlan
that are all subtypes of the currentPlan
type, so that it is not a completely breaking change. (Ideally Plan should be renamed to AbstractPlan, but this would break a lot, I guess)Aside from this, there is also JuliaMath/FFTW.jl#182 , so that ScaledPlans miss the
region
subfield, which could be mitigated by a function likeThe text was updated successfully, but these errors were encountered: