Skip to content

Commit 3d4943d

Browse files
author
Documenter.jl
committed
build based on 6b7954c
1 parent 8f94919 commit 3d4943d

File tree

8 files changed

+9
-9
lines changed

8 files changed

+9
-9
lines changed

dev/abstract/index.html

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,4 +9,4 @@
99
...
1010
end</code></pre><p>We next outline all of the aforementioned functions and describe their behavior:</p><pre><code class="language-julia"> size_in(p)</code></pre><p>Size of the input array for an NFFT operation. The returned tuple has <code>D</code> entries. Note that this will be the output array for an adjoint NFFT.</p><pre><code class="language-julia"> size_out(p)</code></pre><p>Size of the output array for an NFFT operation. The returned tuple has <code>R</code> entries. Note that this will be the input array for an adjoint NFFT.</p><pre><code class="language-julia"> mul!(fHat, p, f) -&gt; fHat</code></pre><p>Inplace NFFT transforming the <code>D</code> dimensional array <code>f</code> to the <code>R</code> dimensional array <code>fHat</code>. The transformation is applied along <code>D-R+1</code> dimensions specified in the plan <code>p</code>. Both <code>f</code> and <code>fHat</code> must be complex arrays of element type <code>Complex{T}</code>.</p><pre><code class="language-julia"> mul!(f, p::Adjoint{Complex{T},&lt;:AbstractNFFTPlan{T}}, fHat) -&gt; f</code></pre><p>Inplace adjoint NFFT transforming the <code>R</code> dimensional array <code>fHat</code> to the <code>D</code> dimensional array <code>f</code>. The transformation is applied along <code>D-R+1</code> dimensions specified in the plan <code>p</code>. Both <code>f</code> and <code>fHat</code> must be complex arrays of element type <code>Complex{T}</code>.</p><pre><code class="language-julia"> nodes!(p, k)</code></pre><p>Exchange the nodes <code>k</code> in the plan <code>p</code> and return the plan. The implementation of this function is optional.</p><h2 id="Plan-Interface"><a class="docs-heading-anchor" href="#Plan-Interface">Plan Interface</a><a id="Plan-Interface-1"></a><a class="docs-heading-anchor-permalink" href="#Plan-Interface" title="Permalink"></a></h2><p>The constructor for a plan also has a defined interface. It should be implemented in this way:</p><pre><code class="language-none">function MyNFFTPlan(k::Matrix{T}, N::NTuple{D,Int}; kwargs...) where {T,D}
1111
...
12-
end</code></pre><p>All parameters are put into keyword arguments that have to match as well. We describe the keyword arguments in more detail in the overview page. Using the same plan interface allows to load several NFFT libraries simultaneously and exchange the constructor dynamically by storing the constructor in a function object. This is how the unit tests of <code>NFFT.jl</code> run.</p><p>Additionally, to the type-specific constructor one can provide the factory</p><pre><code class="language-none">plan_nfft(Q::Type, k::Matrix{T}, N::NTuple{D,Int}; kargs...) where {D}</code></pre><p>where <code>Q</code> is the Array type, e.g. <code>Array</code>. The reason to require the array type is, that this allows for GPU implementations, which would use for instance <code>CuArray</code> here.</p><p>The package <code>AbstractNFFTs</code> provides a convenient constructor</p><pre><code class="language-none">plan_nfft(k::Matrix{T}, N::NTuple{D,Int}; kargs...) where {D}</code></pre><p>defaulting to the <code>Array</code> type.</p><div class="admonition is-info"><header class="admonition-header">Note</header><div class="admonition-body"><p>Different packages implementing <code>plan_nfft</code> will conflict if the same <code>Q</code> is implemented. In case of <code>NFFT.jl</code> and <code>CuNFFT.jl</code> there is no conflict since the array type is different.</p></div></div><h2 id="Derived-Interface"><a class="docs-heading-anchor" href="#Derived-Interface">Derived Interface</a><a id="Derived-Interface-1"></a><a class="docs-heading-anchor-permalink" href="#Derived-Interface" title="Permalink"></a></h2><p>Based on the core low-level interface that an <code>AbstractNFFTPlan</code> needs to provide, the package <code>AbstractNFFT.jl</code> also provides high-level functions like <code>*</code>, <code>nfft</code>, and <code>nfft_adjoint</code>, which internally use the low-level interface. Thus, the implementation of high-level function is shared among all <code>AbstractNFFT.jl</code> implementations.</p></article><nav class="docs-footer"><a class="docs-footer-prevpage" href="../tools/">« Tools</a><a class="docs-footer-nextpage" href="../api/">API »</a><div class="flexbox-break"></div><p class="footer-message">Powered by <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> and the <a href="https://julialang.org/">Julia Programming Language</a>.</p></nav></div><div class="modal" id="documenter-settings"><div class="modal-background"></div><div class="modal-card"><header class="modal-card-head"><p class="modal-card-title">Settings</p><button class="delete"></button></header><section class="modal-card-body"><p><label class="label">Theme</label><div class="select"><select id="documenter-themepicker"><option value="documenter-light">documenter-light</option><option value="documenter-dark">documenter-dark</option></select></div></p><hr/><p>This document was generated with <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> on <span class="colophon-date" title="Thursday 3 April 2025 09:13">Thursday 3 April 2025</span>. Using Julia version 1.11.4.</p></section><footer class="modal-card-foot"></footer></div></div></div></body></html>
12+
end</code></pre><p>All parameters are put into keyword arguments that have to match as well. We describe the keyword arguments in more detail in the overview page. Using the same plan interface allows to load several NFFT libraries simultaneously and exchange the constructor dynamically by storing the constructor in a function object. This is how the unit tests of <code>NFFT.jl</code> run.</p><p>Additionally, to the type-specific constructor one can provide the factory</p><pre><code class="language-none">plan_nfft(Q::Type, k::Matrix{T}, N::NTuple{D,Int}; kargs...) where {D}</code></pre><p>where <code>Q</code> is the Array type, e.g. <code>Array</code>. The reason to require the array type is, that this allows for GPU implementations, which would use for instance <code>CuArray</code> here.</p><p>The package <code>AbstractNFFTs</code> provides a convenient constructor</p><pre><code class="language-none">plan_nfft(k::Matrix{T}, N::NTuple{D,Int}; kargs...) where {D}</code></pre><p>defaulting to the <code>Array</code> type.</p><div class="admonition is-info"><header class="admonition-header">Note</header><div class="admonition-body"><p>Different packages implementing <code>plan_nfft</code> will conflict if the same <code>Q</code> is implemented. In case of <code>NFFT.jl</code> and <code>CuNFFT.jl</code> there is no conflict since the array type is different.</p></div></div><h2 id="Derived-Interface"><a class="docs-heading-anchor" href="#Derived-Interface">Derived Interface</a><a id="Derived-Interface-1"></a><a class="docs-heading-anchor-permalink" href="#Derived-Interface" title="Permalink"></a></h2><p>Based on the core low-level interface that an <code>AbstractNFFTPlan</code> needs to provide, the package <code>AbstractNFFT.jl</code> also provides high-level functions like <code>*</code>, <code>nfft</code>, and <code>nfft_adjoint</code>, which internally use the low-level interface. Thus, the implementation of high-level function is shared among all <code>AbstractNFFT.jl</code> implementations.</p></article><nav class="docs-footer"><a class="docs-footer-prevpage" href="../tools/">« Tools</a><a class="docs-footer-nextpage" href="../api/">API »</a><div class="flexbox-break"></div><p class="footer-message">Powered by <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> and the <a href="https://julialang.org/">Julia Programming Language</a>.</p></nav></div><div class="modal" id="documenter-settings"><div class="modal-background"></div><div class="modal-card"><header class="modal-card-head"><p class="modal-card-title">Settings</p><button class="delete"></button></header><section class="modal-card-body"><p><label class="label">Theme</label><div class="select"><select id="documenter-themepicker"><option value="documenter-light">documenter-light</option><option value="documenter-dark">documenter-dark</option></select></div></p><hr/><p>This document was generated with <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> on <span class="colophon-date" title="Thursday 6 November 2025 08:27">Thursday 6 November 2025</span>. Using Julia version 1.12.1.</p></section><footer class="modal-card-foot"></footer></div></div></div></body></html>

dev/api/index.html

Lines changed: 2 additions & 2 deletions
Large diffs are not rendered by default.

0 commit comments

Comments
 (0)