Mercurial > hg > batch-feature-extraction-tool
diff Lib/fftw-3.2.1/doc/html/.svn/text-base/One_002dDimensional-DFTs-of-Real-Data.html.svn-base @ 15:585caf503ef5 tip
Tidy up for ROLI
| author | Geogaddi\David <d.m.ronan@qmul.ac.uk> |
|---|---|
| date | Tue, 17 May 2016 18:50:19 +0100 |
| parents | 636c989477e7 |
| children |
line wrap: on
line diff
--- a/Lib/fftw-3.2.1/doc/html/.svn/text-base/One_002dDimensional-DFTs-of-Real-Data.html.svn-base Wed May 04 11:02:59 2016 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,139 +0,0 @@ -<html lang="en"> -<head> -<title>One-Dimensional DFTs of Real Data - FFTW 3.2.1</title> -<meta http-equiv="Content-Type" content="text/html"> -<meta name="description" content="FFTW 3.2.1"> -<meta name="generator" content="makeinfo 4.8"> -<link title="Top" rel="start" href="index.html#Top"> -<link rel="up" href="Tutorial.html#Tutorial" title="Tutorial"> -<link rel="prev" href="Complex-Multi_002dDimensional-DFTs.html#Complex-Multi_002dDimensional-DFTs" title="Complex Multi-Dimensional DFTs"> -<link rel="next" href="Multi_002dDimensional-DFTs-of-Real-Data.html#Multi_002dDimensional-DFTs-of-Real-Data" title="Multi-Dimensional DFTs of Real Data"> -<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage"> -<!-- -This manual is for FFTW -(version 3.2.1, 5 February 2009). - -Copyright (C) 2003 Matteo Frigo. - -Copyright (C) 2003 Massachusetts Institute of Technology. - - Permission is granted to make and distribute verbatim copies of - this manual provided the copyright notice and this permission - notice are preserved on all copies. - - Permission is granted to copy and distribute modified versions of - this manual under the conditions for verbatim copying, provided - that the entire resulting derived work is distributed under the - terms of a permission notice identical to this one. - - Permission is granted to copy and distribute translations of this - manual into another language, under the above conditions for - modified versions, except that this permission notice may be - stated in a translation approved by the Free Software Foundation. - --> -<meta http-equiv="Content-Style-Type" content="text/css"> -<style type="text/css"><!-- - pre.display { font-family:inherit } - pre.format { font-family:inherit } - pre.smalldisplay { font-family:inherit; font-size:smaller } - pre.smallformat { font-family:inherit; font-size:smaller } - pre.smallexample { font-size:smaller } - pre.smalllisp { font-size:smaller } - span.sc { font-variant:small-caps } - span.roman { font-family:serif; font-weight:normal; } - span.sansserif { font-family:sans-serif; font-weight:normal; } ---></style> -</head> -<body> -<div class="node"> -<p> -<a name="One-Dimensional-DFTs-of-Real-Data"></a> -<a name="One_002dDimensional-DFTs-of-Real-Data"></a> -Next: <a rel="next" accesskey="n" href="Multi_002dDimensional-DFTs-of-Real-Data.html#Multi_002dDimensional-DFTs-of-Real-Data">Multi-Dimensional DFTs of Real Data</a>, -Previous: <a rel="previous" accesskey="p" href="Complex-Multi_002dDimensional-DFTs.html#Complex-Multi_002dDimensional-DFTs">Complex Multi-Dimensional DFTs</a>, -Up: <a rel="up" accesskey="u" href="Tutorial.html#Tutorial">Tutorial</a> -<hr> -</div> - -<h3 class="section">2.3 One-Dimensional DFTs of Real Data</h3> - -<p>In many practical applications, the input data <code>in[i]</code> are purely -real numbers, in which case the DFT output satisfies the “Hermitian” -<a name="index-Hermitian-45"></a>redundancy: <code>out[i]</code> is the conjugate of <code>out[n-i]</code>. It is -possible to take advantage of these circumstances in order to achieve -roughly a factor of two improvement in both speed and memory usage. - - <p>In exchange for these speed and space advantages, the user sacrifices -some of the simplicity of FFTW's complex transforms. First of all, the -input and output arrays are of <em>different sizes and types</em>: the -input is <code>n</code> real numbers, while the output is <code>n/2+1</code> -complex numbers (the non-redundant outputs); this also requires slight -“padding” of the input array for -<a name="index-padding-46"></a>in-place transforms. Second, the inverse transform (complex to real) -has the side-effect of <em>destroying its input array</em>, by default. -Neither of these inconveniences should pose a serious problem for -users, but it is important to be aware of them. - - <p>The routines to perform real-data transforms are almost the same as -those for complex transforms: you allocate arrays of <code>double</code> -and/or <code>fftw_complex</code> (preferably using <code>fftw_malloc</code>), -create an <code>fftw_plan</code>, execute it as many times as you want with -<code>fftw_execute(plan)</code>, and clean up with -<code>fftw_destroy_plan(plan)</code> (and <code>fftw_free</code>). The only -differences are that the input (or output) is of type <code>double</code> -and there are new routines to create the plan. In one dimension: - -<pre class="example"> fftw_plan fftw_plan_dft_r2c_1d(int n, double *in, fftw_complex *out, - unsigned flags); - fftw_plan fftw_plan_dft_c2r_1d(int n, fftw_complex *in, double *out, - unsigned flags); -</pre> - <p><a name="index-fftw_005fplan_005fdft_005fr2c_005f1d-47"></a><a name="index-fftw_005fplan_005fdft_005fc2r_005f1d-48"></a> -for the real input to complex-Hermitian output (<dfn>r2c</dfn>) and -complex-Hermitian input to real output (<dfn>c2r</dfn>) transforms. -<a name="index-r2c-49"></a><a name="index-c2r-50"></a>Unlike the complex DFT planner, there is no <code>sign</code> argument. -Instead, r2c DFTs are always <code>FFTW_FORWARD</code> and c2r DFTs are -always <code>FFTW_BACKWARD</code>. -<a name="index-FFTW_005fFORWARD-51"></a><a name="index-FFTW_005fBACKWARD-52"></a>(For single/long-double precision -<code>fftwf</code> and <code>fftwl</code>, <code>double</code> should be replaced by -<code>float</code> and <code>long double</code>, respectively.) -<a name="index-precision-53"></a> -Here, <code>n</code> is the “logical” size of the DFT, not necessarily the -physical size of the array. In particular, the real (<code>double</code>) -array has <code>n</code> elements, while the complex (<code>fftw_complex</code>) -array has <code>n/2+1</code> elements (where the division is rounded down). -For an in-place transform, -<a name="index-in_002dplace-54"></a><code>in</code> and <code>out</code> are aliased to the same array, which must be -big enough to hold both; so, the real array would actually have -<code>2*(n/2+1)</code> elements, where the elements beyond the first <code>n</code> -are unused padding. The kth element of the complex array is -exactly the same as the kth element of the corresponding complex -DFT. All positive <code>n</code> are supported; products of small factors are -most efficient, but an <i>O</i>(<i>n</i> log <i>n</i>) algorithm is used even for prime -sizes. - - <p>As noted above, the c2r transform destroys its input array even for -out-of-place transforms. This can be prevented, if necessary, by -including <code>FFTW_PRESERVE_INPUT</code> in the <code>flags</code>, with -unfortunately some sacrifice in performance. -<a name="index-flags-55"></a><a name="index-FFTW_005fPRESERVE_005fINPUT-56"></a>This flag is also not currently supported for multi-dimensional real -DFTs (next section). - - <p>Readers familiar with DFTs of real data will recall that the 0th (the -“DC”) and <code>n/2</code>-th (the “Nyquist” frequency, when <code>n</code> is -even) elements of the complex output are purely real. Some -implementations therefore store the Nyquist element where the DC -imaginary part would go, in order to make the input and output arrays -the same size. Such packing, however, does not generalize well to -multi-dimensional transforms, and the space savings are miniscule in -any case; FFTW does not support it. - - <p>An alternative interface for one-dimensional r2c and c2r DFTs can be -found in the `<samp><span class="samp">r2r</span></samp>' interface (see <a href="The-Halfcomplex_002dformat-DFT.html#The-Halfcomplex_002dformat-DFT">The Halfcomplex-format DFT</a>), with “halfcomplex”-format output that <em>is</em> the same size -(and type) as the input array. -<a name="index-halfcomplex-format-57"></a>That interface, although it is not very useful for multi-dimensional -transforms, may sometimes yield better performance. - -<!-- --> -</body></html> -