-
Notifications
You must be signed in to change notification settings - Fork 33
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
Rename ProjectionStyle -> AdjointStyle, _mul -> AdjointMul, and improve docs #109
Conversation
…ckages. add a few lines of docs
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #109 +/- ##
==========================================
- Coverage 92.04% 91.43% -0.61%
==========================================
Files 3 3
Lines 289 292 +3
==========================================
+ Hits 266 267 +1
- Misses 23 25 +2
☔ View full report in Codecov by Sentry. |
It's a fair point about the name: I think it's still flexible, @devmotion @sethaxen would you agree? What about Please feel free to suggest what you think might be clearest? Edit: We could even make the trait the function itself... i.e. we have a trait like |
i like the idea of renaming them FFTAdjointStyle, etc and three trait idea |
docs/src/implementations.md
Outdated
* `AbstractFFTs.NoProjectionStyle()`, | ||
* `AbstractFFTs.RealProjectionStyle()`, for plans that halve one of the output's dimensions analogously to [`rfft`](@ref), | ||
* `AbstractFFTs.RealInverseProjectionStyle(d::Int)`, for plans that expect an input with a halved dimension analogously to [`irfft`](@ref), where `d` is the original length of the dimension. | ||
* We offer an experimental `AdjointStyle` trait to enable automatic computation of adjoint plans via [`Base.adjoint`](@ref). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is the trait experimental? And what exactly is experimental? I guess downstream packages would be interested in what parts (if any) are considered stable, if every patch release may break things etc.
docs/src/implementations.md
Outdated
To support adjoints in a new plan, define the trait `AbstractFFTs.AdjointStyle(::MyPlan)`. This should return a subtype of `AS <: AbstractFFTs.AdjointStyle` supporting `AbstractFFTs.adjoint_mul(::Plan, ::AbstractArray, ::AS)` and | ||
`AbstractFFTs._output_size(::Plan, ::AS)`. | ||
|
||
`AbstractFFTs` pre-implements the following adjoint styles: [`AbstractFFTs.FFTAdjointStyle`](@ref), [`AbstractFFTs.RFFTAdjointStyle`](@ref), [`AbstractFFTs.IRFFTAdjointStyle`](@ref), and [`AbstractFFTs.UnitaryAdjointStyle`](@ref). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is meant with pre-implements
? AFAICT the package implements these styles? Or is there anything missing?
docs/src/implementations.md
Outdated
* `AbstractFFTs.RealProjectionStyle()`, for plans that halve one of the output's dimensions analogously to [`rfft`](@ref), | ||
* `AbstractFFTs.RealInverseProjectionStyle(d::Int)`, for plans that expect an input with a halved dimension analogously to [`irfft`](@ref), where `d` is the original length of the dimension. | ||
* We offer an experimental `AdjointStyle` trait to enable automatic computation of adjoint plans via [`Base.adjoint`](@ref). | ||
To support adjoints in a new plan, define the trait `AbstractFFTs.AdjointStyle(::MyPlan)`. This should return a subtype of `AS <: AbstractFFTs.AdjointStyle` supporting `AbstractFFTs.adjoint_mul(::Plan, ::AbstractArray, ::AS)` and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I.e., adjoint_mul
is part of the API?
docs/src/implementations.md
Outdated
* `AbstractFFTs.RealInverseProjectionStyle(d::Int)`, for plans that expect an input with a halved dimension analogously to [`irfft`](@ref), where `d` is the original length of the dimension. | ||
* We offer an experimental `AdjointStyle` trait to enable automatic computation of adjoint plans via [`Base.adjoint`](@ref). | ||
To support adjoints in a new plan, define the trait `AbstractFFTs.AdjointStyle(::MyPlan)`. This should return a subtype of `AS <: AbstractFFTs.AdjointStyle` supporting `AbstractFFTs.adjoint_mul(::Plan, ::AbstractArray, ::AS)` and | ||
`AbstractFFTs._output_size(::Plan, ::AS)`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume _output_size
should be implemented as well? Could we just rename it to output_size
? To me the underscore suggests that it is an internal method.
Thanks for the comments, I've revised the PR. |
Right, fixed. |
Bump on this or #78 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
Thanks! I don't have merge privileges so please merge when ready 🙂 (after merge I can fix merge conflicts in #78) |
This PR makes the projection styles subtypes of an abstract type. This is so that new projection styles can be added in downstream packages. In FFTW.jl, we are defining projection styles for DCT and FFTW.R2R transforms in JuliaMath/FFTW.jl#249.
@gaurav-arya can you add a few lines of documentation for the different ProjectionStyles? For example,
fft
function does each projection style correspond to?I fear that the names are slightly confusing. Specifically,NoProjectionStyle
made it seem like it would be applicable to unitary transforms. But it looks likeNoProjectionStyle
is applicable tofft/bfft
.