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

Rename ProjectionStyle -> AdjointStyle, _mul -> AdjointMul, and improve docs #109

Merged
merged 9 commits into from
Jul 27, 2023

Conversation

vpuri3
Copy link
Contributor

@vpuri3 vpuri3 commented Jul 9, 2023

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,

  • which fft function does each projection style correspond to?
  • what is the normalization scheme involved

I fear that the names are slightly confusing. Specifically, NoProjectionStyle made it seem like it would be applicable to unitary transforms. But it looks like NoProjectionStyle is applicable to fft/bfft.

@codecov
Copy link

codecov bot commented Jul 9, 2023

Codecov Report

Patch coverage: 92.85% and project coverage change: -0.61 ⚠️

Comparison is base (1cc9ca0) 92.04% compared to head (bc6bee8) 91.43%.

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     
Impacted Files Coverage Δ
src/definitions.jl 82.99% <92.85%> (-1.04%) ⬇️

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

@gaurav-arya
Copy link
Contributor

gaurav-arya commented Jul 9, 2023

It's a fair point about the name: I think it's still flexible, @devmotion @sethaxen would you agree? What about AdjointStyle rather than ProjectionStyle, since we have to write out the full adjoint def anyway for each projection style? And then just being direct, e.g. FFTAdjointStyle, RFFTAdjointStyle, IRFFTAdjointStyle, etc.

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 plan_function where a plan tells us which function its trying to compute (fft, rfft, brfft, dct, etc.), and then we have adjoint dispatches for those functions like ::typeof(fft) (where we'd reuse the same underlying logic for e.g. brfft and irfft).

@vpuri3
Copy link
Contributor Author

vpuri3 commented Jul 9, 2023

i like the idea of renaming them FFTAdjointStyle, etc and three trait idea

@vpuri3 vpuri3 changed the title make ProjectionStyle abstract type Rename ProjectionStyle -> AdjointStyle, _mul -> AdjointMul, and improve docs Jul 18, 2023
* `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).
Copy link
Member

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.

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).
Copy link
Member

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?

* `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
Copy link
Member

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?

* `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)`.
Copy link
Member

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.

@gaurav-arya
Copy link
Contributor

Thanks for the comments, I've revised the PR.

src/definitions.jl Outdated Show resolved Hide resolved
@gaurav-arya
Copy link
Contributor

Right, fixed.

@gaurav-arya
Copy link
Contributor

Bump on this or #78

Copy link
Member

@devmotion devmotion left a 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.

@gaurav-arya
Copy link
Contributor

gaurav-arya commented Jul 27, 2023

Thanks! I don't have merge privileges so please merge when ready 🙂 (after merge I can fix merge conflicts in #78)

@devmotion devmotion merged commit 5c23f4b into JuliaMath:master Jul 27, 2023
@vpuri3 vpuri3 deleted the proj branch January 18, 2024 13:26
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

Successfully merging this pull request may close these issues.

3 participants