Chris@10: Chris@10: Chris@10: Real-data DFT Array Format - FFTW 3.3.3 Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10:
Chris@10: Chris@10: Chris@10:

Chris@10: Next: , Chris@10: Previous: Real-data DFTs, Chris@10: Up: Basic Interface Chris@10:


Chris@10:
Chris@10: Chris@10:

4.3.4 Real-data DFT Array Format

Chris@10: Chris@10:

Chris@10: The output of a DFT of real data (r2c) contains symmetries that, in Chris@10: principle, make half of the outputs redundant (see What FFTW Really Computes). (Similarly for the input of an inverse c2r transform.) In Chris@10: practice, it is not possible to entirely realize these savings in an Chris@10: efficient and understandable format that generalizes to Chris@10: multi-dimensional transforms. Instead, the output of the r2c Chris@10: transforms is slightly over half of the output of the Chris@10: corresponding complex transform. We do not “pack” the data in any Chris@10: way, but store it as an ordinary array of fftw_complex values. Chris@10: In fact, this data is simply a subsection of what would be the array in Chris@10: the corresponding complex transform. Chris@10: Chris@10:

Specifically, for a real transform of d (= rank) Chris@10: dimensions n0 × n1 × n2 × … × nd-1, the complex data is an n0 × n1 × n2 × … × (nd-1/2 + 1) array of Chris@10: fftw_complex values in row-major order (with the division rounded Chris@10: down). That is, we only store the lower half (non-negative Chris@10: frequencies), plus one element, of the last dimension of the data from Chris@10: the ordinary complex transform. (We could have instead taken half of Chris@10: any other dimension, but implementation turns out to be simpler if the Chris@10: last, contiguous, dimension is used.) Chris@10: Chris@10:

For an out-of-place transform, the real data is simply an array with Chris@10: physical dimensions n0 × n1 × n2 × … × nd-1 in row-major order. Chris@10: Chris@10:

For an in-place transform, some complications arise since the complex data Chris@10: is slightly larger than the real data. In this case, the final Chris@10: dimension of the real data must be padded with extra values to Chris@10: accommodate the size of the complex data—two extra if the last Chris@10: dimension is even and one if it is odd. That is, the last dimension of Chris@10: the real data must physically contain Chris@10: 2 * (nd-1/2+1)double values (exactly enough to hold the complex data). This Chris@10: physical array size does not, however, change the logical array Chris@10: size—only Chris@10: nd-1values are actually stored in the last dimension, and Chris@10: nd-1is the last dimension passed to the planner. Chris@10: Chris@10: Chris@10: Chris@10: