d@0
|
1 <html lang="en">
|
d@0
|
2 <head>
|
d@0
|
3 <title>One-Dimensional DFTs of Real Data - FFTW 3.2.1</title>
|
d@0
|
4 <meta http-equiv="Content-Type" content="text/html">
|
d@0
|
5 <meta name="description" content="FFTW 3.2.1">
|
d@0
|
6 <meta name="generator" content="makeinfo 4.8">
|
d@0
|
7 <link title="Top" rel="start" href="index.html#Top">
|
d@0
|
8 <link rel="up" href="Tutorial.html#Tutorial" title="Tutorial">
|
d@0
|
9 <link rel="prev" href="Complex-Multi_002dDimensional-DFTs.html#Complex-Multi_002dDimensional-DFTs" title="Complex Multi-Dimensional DFTs">
|
d@0
|
10 <link rel="next" href="Multi_002dDimensional-DFTs-of-Real-Data.html#Multi_002dDimensional-DFTs-of-Real-Data" title="Multi-Dimensional DFTs of Real Data">
|
d@0
|
11 <link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
d@0
|
12 <!--
|
d@0
|
13 This manual is for FFTW
|
d@0
|
14 (version 3.2.1, 5 February 2009).
|
d@0
|
15
|
d@0
|
16 Copyright (C) 2003 Matteo Frigo.
|
d@0
|
17
|
d@0
|
18 Copyright (C) 2003 Massachusetts Institute of Technology.
|
d@0
|
19
|
d@0
|
20 Permission is granted to make and distribute verbatim copies of
|
d@0
|
21 this manual provided the copyright notice and this permission
|
d@0
|
22 notice are preserved on all copies.
|
d@0
|
23
|
d@0
|
24 Permission is granted to copy and distribute modified versions of
|
d@0
|
25 this manual under the conditions for verbatim copying, provided
|
d@0
|
26 that the entire resulting derived work is distributed under the
|
d@0
|
27 terms of a permission notice identical to this one.
|
d@0
|
28
|
d@0
|
29 Permission is granted to copy and distribute translations of this
|
d@0
|
30 manual into another language, under the above conditions for
|
d@0
|
31 modified versions, except that this permission notice may be
|
d@0
|
32 stated in a translation approved by the Free Software Foundation.
|
d@0
|
33 -->
|
d@0
|
34 <meta http-equiv="Content-Style-Type" content="text/css">
|
d@0
|
35 <style type="text/css"><!--
|
d@0
|
36 pre.display { font-family:inherit }
|
d@0
|
37 pre.format { font-family:inherit }
|
d@0
|
38 pre.smalldisplay { font-family:inherit; font-size:smaller }
|
d@0
|
39 pre.smallformat { font-family:inherit; font-size:smaller }
|
d@0
|
40 pre.smallexample { font-size:smaller }
|
d@0
|
41 pre.smalllisp { font-size:smaller }
|
d@0
|
42 span.sc { font-variant:small-caps }
|
d@0
|
43 span.roman { font-family:serif; font-weight:normal; }
|
d@0
|
44 span.sansserif { font-family:sans-serif; font-weight:normal; }
|
d@0
|
45 --></style>
|
d@0
|
46 </head>
|
d@0
|
47 <body>
|
d@0
|
48 <div class="node">
|
d@0
|
49 <p>
|
d@0
|
50 <a name="One-Dimensional-DFTs-of-Real-Data"></a>
|
d@0
|
51 <a name="One_002dDimensional-DFTs-of-Real-Data"></a>
|
d@0
|
52 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>,
|
d@0
|
53 Previous: <a rel="previous" accesskey="p" href="Complex-Multi_002dDimensional-DFTs.html#Complex-Multi_002dDimensional-DFTs">Complex Multi-Dimensional DFTs</a>,
|
d@0
|
54 Up: <a rel="up" accesskey="u" href="Tutorial.html#Tutorial">Tutorial</a>
|
d@0
|
55 <hr>
|
d@0
|
56 </div>
|
d@0
|
57
|
d@0
|
58 <h3 class="section">2.3 One-Dimensional DFTs of Real Data</h3>
|
d@0
|
59
|
d@0
|
60 <p>In many practical applications, the input data <code>in[i]</code> are purely
|
d@0
|
61 real numbers, in which case the DFT output satisfies the “Hermitian”
|
d@0
|
62 <a name="index-Hermitian-45"></a>redundancy: <code>out[i]</code> is the conjugate of <code>out[n-i]</code>. It is
|
d@0
|
63 possible to take advantage of these circumstances in order to achieve
|
d@0
|
64 roughly a factor of two improvement in both speed and memory usage.
|
d@0
|
65
|
d@0
|
66 <p>In exchange for these speed and space advantages, the user sacrifices
|
d@0
|
67 some of the simplicity of FFTW's complex transforms. First of all, the
|
d@0
|
68 input and output arrays are of <em>different sizes and types</em>: the
|
d@0
|
69 input is <code>n</code> real numbers, while the output is <code>n/2+1</code>
|
d@0
|
70 complex numbers (the non-redundant outputs); this also requires slight
|
d@0
|
71 “padding” of the input array for
|
d@0
|
72 <a name="index-padding-46"></a>in-place transforms. Second, the inverse transform (complex to real)
|
d@0
|
73 has the side-effect of <em>destroying its input array</em>, by default.
|
d@0
|
74 Neither of these inconveniences should pose a serious problem for
|
d@0
|
75 users, but it is important to be aware of them.
|
d@0
|
76
|
d@0
|
77 <p>The routines to perform real-data transforms are almost the same as
|
d@0
|
78 those for complex transforms: you allocate arrays of <code>double</code>
|
d@0
|
79 and/or <code>fftw_complex</code> (preferably using <code>fftw_malloc</code>),
|
d@0
|
80 create an <code>fftw_plan</code>, execute it as many times as you want with
|
d@0
|
81 <code>fftw_execute(plan)</code>, and clean up with
|
d@0
|
82 <code>fftw_destroy_plan(plan)</code> (and <code>fftw_free</code>). The only
|
d@0
|
83 differences are that the input (or output) is of type <code>double</code>
|
d@0
|
84 and there are new routines to create the plan. In one dimension:
|
d@0
|
85
|
d@0
|
86 <pre class="example"> fftw_plan fftw_plan_dft_r2c_1d(int n, double *in, fftw_complex *out,
|
d@0
|
87 unsigned flags);
|
d@0
|
88 fftw_plan fftw_plan_dft_c2r_1d(int n, fftw_complex *in, double *out,
|
d@0
|
89 unsigned flags);
|
d@0
|
90 </pre>
|
d@0
|
91 <p><a name="index-fftw_005fplan_005fdft_005fr2c_005f1d-47"></a><a name="index-fftw_005fplan_005fdft_005fc2r_005f1d-48"></a>
|
d@0
|
92 for the real input to complex-Hermitian output (<dfn>r2c</dfn>) and
|
d@0
|
93 complex-Hermitian input to real output (<dfn>c2r</dfn>) transforms.
|
d@0
|
94 <a name="index-r2c-49"></a><a name="index-c2r-50"></a>Unlike the complex DFT planner, there is no <code>sign</code> argument.
|
d@0
|
95 Instead, r2c DFTs are always <code>FFTW_FORWARD</code> and c2r DFTs are
|
d@0
|
96 always <code>FFTW_BACKWARD</code>.
|
d@0
|
97 <a name="index-FFTW_005fFORWARD-51"></a><a name="index-FFTW_005fBACKWARD-52"></a>(For single/long-double precision
|
d@0
|
98 <code>fftwf</code> and <code>fftwl</code>, <code>double</code> should be replaced by
|
d@0
|
99 <code>float</code> and <code>long double</code>, respectively.)
|
d@0
|
100 <a name="index-precision-53"></a>
|
d@0
|
101 Here, <code>n</code> is the “logical” size of the DFT, not necessarily the
|
d@0
|
102 physical size of the array. In particular, the real (<code>double</code>)
|
d@0
|
103 array has <code>n</code> elements, while the complex (<code>fftw_complex</code>)
|
d@0
|
104 array has <code>n/2+1</code> elements (where the division is rounded down).
|
d@0
|
105 For an in-place transform,
|
d@0
|
106 <a name="index-in_002dplace-54"></a><code>in</code> and <code>out</code> are aliased to the same array, which must be
|
d@0
|
107 big enough to hold both; so, the real array would actually have
|
d@0
|
108 <code>2*(n/2+1)</code> elements, where the elements beyond the first <code>n</code>
|
d@0
|
109 are unused padding. The kth element of the complex array is
|
d@0
|
110 exactly the same as the kth element of the corresponding complex
|
d@0
|
111 DFT. All positive <code>n</code> are supported; products of small factors are
|
d@0
|
112 most efficient, but an <i>O</i>(<i>n</i> log <i>n</i>) algorithm is used even for prime
|
d@0
|
113 sizes.
|
d@0
|
114
|
d@0
|
115 <p>As noted above, the c2r transform destroys its input array even for
|
d@0
|
116 out-of-place transforms. This can be prevented, if necessary, by
|
d@0
|
117 including <code>FFTW_PRESERVE_INPUT</code> in the <code>flags</code>, with
|
d@0
|
118 unfortunately some sacrifice in performance.
|
d@0
|
119 <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
|
d@0
|
120 DFTs (next section).
|
d@0
|
121
|
d@0
|
122 <p>Readers familiar with DFTs of real data will recall that the 0th (the
|
d@0
|
123 “DC”) and <code>n/2</code>-th (the “Nyquist” frequency, when <code>n</code> is
|
d@0
|
124 even) elements of the complex output are purely real. Some
|
d@0
|
125 implementations therefore store the Nyquist element where the DC
|
d@0
|
126 imaginary part would go, in order to make the input and output arrays
|
d@0
|
127 the same size. Such packing, however, does not generalize well to
|
d@0
|
128 multi-dimensional transforms, and the space savings are miniscule in
|
d@0
|
129 any case; FFTW does not support it.
|
d@0
|
130
|
d@0
|
131 <p>An alternative interface for one-dimensional r2c and c2r DFTs can be
|
d@0
|
132 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
|
d@0
|
133 (and type) as the input array.
|
d@0
|
134 <a name="index-halfcomplex-format-57"></a>That interface, although it is not very useful for multi-dimensional
|
d@0
|
135 transforms, may sometimes yield better performance.
|
d@0
|
136
|
d@0
|
137 <!-- -->
|
d@0
|
138 </body></html>
|
d@0
|
139
|