Mercurial > hg > js-dsp-test

annotate fft/fftw/fftw-3.3.4/doc/html/One_002dDimensional-DFTs-of-Real-Data.html @ 40:223f770b5341 kissfft-double tip

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