Backend based AbstractNFFT implementation #149
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed in here, it is currently not possible to use the
plan_nfft
interface when multiple packages such as NFFT and NonuniformFFTs are loaded in the same session. The underlying issue is that both packages refer to the same function and usually have no dedicated type to dispatch one, as both want to dispatch on "normal" user array types.This PR adds a "backend"-based selection of the NFFT plan implementation, which allows a user to chose which backend to use for a given
plan_nfft
call. This utilizes an additional first parameter which specifies the backend to use:To hide this additional type from the users of upstream packages, AbstractNFFTs now features an active backend global constant, similar to how Makie allows one to switch between its backends:
This PR allows upstream packages such as LinearOperatorCollection (PR) or MRIOperators to define themselves in terms of AbstractNFFTs and use exchangable NFFT providers.