Chris@10: Next: Wisdom, Chris@10: Previous: Guru Interface, Chris@10: Up: FFTW Reference Chris@10:
Chris@10: Normally, one executes a plan for the arrays with which the plan was
Chris@10: created, by calling fftw_execute(plan) as described in Using Plans.
Chris@10: However, it is possible for sophisticated users to apply a given plan
Chris@10: to a different array using the “new-array execute” functions
Chris@10: detailed below, provided that the following conditions are met:
Chris@10:
Chris@10:
ii-ri and io-ro, are the same as they were for
Chris@10: the input and output arrays when the plan was created. (This
Chris@10: condition is automatically satisfied for interleaved arrays.)
Chris@10:
Chris@10: FFTW_UNALIGNED flag.
Chris@10: Here, the alignment is a platform-dependent quantity (for example, it is
Chris@10: the address modulo 16 if SSE SIMD instructions are used, but the address
Chris@10: modulo 4 for non-SIMD single-precision FFTW on the same machine). In
Chris@10: general, only arrays allocated with fftw_malloc are guaranteed to
Chris@10: be equally aligned (see SIMD alignment and fftw_malloc).
Chris@10:
Chris@10: The alignment issue is especially critical, because if you don't use
Chris@10: fftw_malloc then you may have little control over the alignment
Chris@10: of arrays in memory. For example, neither the C++ new function
Chris@10: nor the Fortran allocate statement provide strong enough
Chris@10: guarantees about data alignment. If you don't use fftw_malloc,
Chris@10: therefore, you probably have to use FFTW_UNALIGNED (which
Chris@10: disables most SIMD support). If possible, it is probably better for
Chris@10: you to simply create multiple plans (creating a new plan is quick once
Chris@10: one exists for a given size), or better yet re-use the same array for
Chris@10: your transforms.
Chris@10:
Chris@10:
If you are tempted to use the new-array execute interface because you Chris@10: want to transform a known bunch of arrays of the same size, you should Chris@10: probably go use the advanced interface instead (see Advanced Interface)). Chris@10: Chris@10:
The new-array execute functions are: Chris@10: Chris@10:
void fftw_execute_dft( Chris@10: const fftw_plan p, Chris@10: fftw_complex *in, fftw_complex *out); Chris@10: Chris@10: void fftw_execute_split_dft( Chris@10: const fftw_plan p, Chris@10: double *ri, double *ii, double *ro, double *io); Chris@10: Chris@10: void fftw_execute_dft_r2c( Chris@10: const fftw_plan p, Chris@10: double *in, fftw_complex *out); Chris@10: Chris@10: void fftw_execute_split_dft_r2c( Chris@10: const fftw_plan p, Chris@10: double *in, double *ro, double *io); Chris@10: Chris@10: void fftw_execute_dft_c2r( Chris@10: const fftw_plan p, Chris@10: fftw_complex *in, double *out); Chris@10: Chris@10: void fftw_execute_split_dft_c2r( Chris@10: const fftw_plan p, Chris@10: double *ri, double *ii, double *out); Chris@10: Chris@10: void fftw_execute_r2r( Chris@10: const fftw_plan p, Chris@10: double *in, double *out); Chris@10:Chris@10:
Chris@10: These execute the plan to compute the corresponding transform on
Chris@10: the input/output arrays specified by the subsequent arguments. The
Chris@10: input/output array arguments have the same meanings as the ones passed
Chris@10: to the guru planner routines in the preceding sections. The plan
Chris@10: is not modified, and these routines can be called as many times as
Chris@10: desired, or intermixed with calls to the ordinary fftw_execute.
Chris@10:
Chris@10:
The plan must have been created for the transform type
Chris@10: corresponding to the execute function, e.g. it must be a complex-DFT
Chris@10: plan for fftw_execute_dft. Any of the planner routines for that
Chris@10: transform type, from the basic to the guru interface, could have been
Chris@10: used to create the plan, however.
Chris@10:
Chris@10:
Chris@10:
Chris@10: