annotate fft/fftw/fftw-3.3.4/doc/FAQ/fftw-faq.ascii @ 40:223f770b5341 kissfft-double tip

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 FFTW FREQUENTLY ASKED QUESTIONS WITH ANSWERS
Chris@19 2 04 Mar 2014
Chris@19 3 Matteo Frigo
Chris@19 4 Steven G. Johnson
Chris@19 5 <fftw@fftw.org>
Chris@19 6
Chris@19 7 This is the list of Frequently Asked Questions about FFTW, a collection of
Chris@19 8 fast C routines for computing the Discrete Fourier Transform in one or
Chris@19 9 more dimensions.
Chris@19 10
Chris@19 11 ===============================================================================
Chris@19 12
Chris@19 13 Index
Chris@19 14
Chris@19 15 Section 1. Introduction and General Information
Chris@19 16 Q1.1 What is FFTW?
Chris@19 17 Q1.2 How do I obtain FFTW?
Chris@19 18 Q1.3 Is FFTW free software?
Chris@19 19 Q1.4 What is this about non-free licenses?
Chris@19 20 Q1.5 In the West? I thought MIT was in the East?
Chris@19 21
Chris@19 22 Section 2. Installing FFTW
Chris@19 23 Q2.1 Which systems does FFTW run on?
Chris@19 24 Q2.2 Does FFTW run on Windows?
Chris@19 25 Q2.3 My compiler has trouble with FFTW.
Chris@19 26 Q2.4 FFTW does not compile on Solaris, complaining about const.
Chris@19 27 Q2.5 What's the difference between --enable-3dnow and --enable-k7?
Chris@19 28 Q2.6 What's the difference between the fma and the non-fma versions?
Chris@19 29 Q2.7 Which language is FFTW written in?
Chris@19 30 Q2.8 Can I call FFTW from Fortran?
Chris@19 31 Q2.9 Can I call FFTW from C++?
Chris@19 32 Q2.10 Why isn't FFTW written in Fortran/C++?
Chris@19 33 Q2.11 How do I compile FFTW to run in single precision?
Chris@19 34 Q2.12 --enable-k7 does not work on x86-64
Chris@19 35
Chris@19 36 Section 3. Using FFTW
Chris@19 37 Q3.1 Why not support the FFTW 2 interface in FFTW 3?
Chris@19 38 Q3.2 Why do FFTW 3 plans encapsulate the input/output arrays and not ju
Chris@19 39 Q3.3 FFTW seems really slow.
Chris@19 40 Q3.4 FFTW slows down after repeated calls.
Chris@19 41 Q3.5 An FFTW routine is crashing when I call it.
Chris@19 42 Q3.6 My Fortran program crashes when calling FFTW.
Chris@19 43 Q3.7 FFTW gives results different from my old FFT.
Chris@19 44 Q3.8 FFTW gives different results between runs
Chris@19 45 Q3.9 Can I save FFTW's plans?
Chris@19 46 Q3.10 Why does your inverse transform return a scaled result?
Chris@19 47 Q3.11 How can I make FFTW put the origin (zero frequency) at the center
Chris@19 48 Q3.12 How do I FFT an image/audio file in *foobar* format?
Chris@19 49 Q3.13 My program does not link (on Unix).
Chris@19 50 Q3.14 I included your header, but linking still fails.
Chris@19 51 Q3.15 My program crashes, complaining about stack space.
Chris@19 52 Q3.16 FFTW seems to have a memory leak.
Chris@19 53 Q3.17 The output of FFTW's transform is all zeros.
Chris@19 54 Q3.18 How do I call FFTW from the Microsoft language du jour?
Chris@19 55 Q3.19 Can I compute only a subset of the DFT outputs?
Chris@19 56 Q3.20 Can I use FFTW's routines for in-place and out-of-place matrix tra
Chris@19 57
Chris@19 58 Section 4. Internals of FFTW
Chris@19 59 Q4.1 How does FFTW work?
Chris@19 60 Q4.2 Why is FFTW so fast?
Chris@19 61
Chris@19 62 Section 5. Known bugs
Chris@19 63 Q5.1 FFTW 1.1 crashes in rfftwnd on Linux.
Chris@19 64 Q5.2 The MPI transforms in FFTW 1.2 give incorrect results/leak memory.
Chris@19 65 Q5.3 The test programs in FFTW 1.2.1 fail when I change FFTW to use sin
Chris@19 66 Q5.4 The test program in FFTW 1.2.1 fails for n > 46340.
Chris@19 67 Q5.5 The threaded code fails on Linux Redhat 5.0
Chris@19 68 Q5.6 FFTW 2.0's rfftwnd fails for rank > 1 transforms with a final dime
Chris@19 69 Q5.7 FFTW 2.0's complex transforms give the wrong results with prime fa
Chris@19 70 Q5.8 FFTW 2.1.1's MPI test programs crash with MPICH.
Chris@19 71 Q5.9 FFTW 2.1.2's multi-threaded transforms don't work on AIX.
Chris@19 72 Q5.10 FFTW 2.1.2's complex transforms give incorrect results for large p
Chris@19 73 Q5.11 FFTW 2.1.3's multi-threaded transforms don't give any speedup on S
Chris@19 74 Q5.12 FFTW 2.1.3 crashes on AIX.
Chris@19 75
Chris@19 76 ===============================================================================
Chris@19 77
Chris@19 78 Section 1. Introduction and General Information
Chris@19 79
Chris@19 80 Q1.1 What is FFTW?
Chris@19 81 Q1.2 How do I obtain FFTW?
Chris@19 82 Q1.3 Is FFTW free software?
Chris@19 83 Q1.4 What is this about non-free licenses?
Chris@19 84 Q1.5 In the West? I thought MIT was in the East?
Chris@19 85
Chris@19 86 -------------------------------------------------------------------------------
Chris@19 87
Chris@19 88 Question 1.1. What is FFTW?
Chris@19 89
Chris@19 90 FFTW is a free collection of fast C routines for computing the Discrete
Chris@19 91 Fourier Transform in one or more dimensions. It includes complex, real,
Chris@19 92 symmetric, and parallel transforms, and can handle arbitrary array sizes
Chris@19 93 efficiently. FFTW is typically faster than other publically-available FFT
Chris@19 94 implementations, and is even competitive with vendor-tuned libraries.
Chris@19 95 (See our web page for extensive benchmarks.) To achieve this performance,
Chris@19 96 FFTW uses novel code-generation and runtime self-optimization techniques
Chris@19 97 (along with many other tricks).
Chris@19 98
Chris@19 99 -------------------------------------------------------------------------------
Chris@19 100
Chris@19 101 Question 1.2. How do I obtain FFTW?
Chris@19 102
Chris@19 103 FFTW can be found at the FFTW web page. You can also retrieve it from
Chris@19 104 ftp.fftw.org in /pub/fftw.
Chris@19 105
Chris@19 106 -------------------------------------------------------------------------------
Chris@19 107
Chris@19 108 Question 1.3. Is FFTW free software?
Chris@19 109
Chris@19 110 Starting with version 1.3, FFTW is Free Software in the technical sense
Chris@19 111 defined by the Free Software Foundation (see Categories of Free and
Chris@19 112 Non-Free Software), and is distributed under the terms of the GNU General
Chris@19 113 Public License. Previous versions of FFTW were distributed without fee
Chris@19 114 for noncommercial use, but were not technically ``free.''
Chris@19 115
Chris@19 116 Non-free licenses for FFTW are also available that permit different terms
Chris@19 117 of use than the GPL.
Chris@19 118
Chris@19 119 -------------------------------------------------------------------------------
Chris@19 120
Chris@19 121 Question 1.4. What is this about non-free licenses?
Chris@19 122
Chris@19 123 The non-free licenses are for companies that wish to use FFTW in their
Chris@19 124 products but are unwilling to release their software under the GPL (which
Chris@19 125 would require them to release source code and allow free redistribution).
Chris@19 126 Such users can purchase an unlimited-use license from MIT. Contact us for
Chris@19 127 more details.
Chris@19 128
Chris@19 129 We could instead have released FFTW under the LGPL, or even disallowed
Chris@19 130 non-Free usage. Suffice it to say, however, that MIT owns the copyright
Chris@19 131 to FFTW and they only let us GPL it because we convinced them that it
Chris@19 132 would neither affect their licensing revenue nor irritate existing
Chris@19 133 licensees.
Chris@19 134
Chris@19 135 -------------------------------------------------------------------------------
Chris@19 136
Chris@19 137 Question 1.5. In the West? I thought MIT was in the East?
Chris@19 138
Chris@19 139 Not to an Italian. You could say that we're a Spaghetti Western (with
Chris@19 140 apologies to Sergio Leone).
Chris@19 141
Chris@19 142 ===============================================================================
Chris@19 143
Chris@19 144 Section 2. Installing FFTW
Chris@19 145
Chris@19 146 Q2.1 Which systems does FFTW run on?
Chris@19 147 Q2.2 Does FFTW run on Windows?
Chris@19 148 Q2.3 My compiler has trouble with FFTW.
Chris@19 149 Q2.4 FFTW does not compile on Solaris, complaining about const.
Chris@19 150 Q2.5 What's the difference between --enable-3dnow and --enable-k7?
Chris@19 151 Q2.6 What's the difference between the fma and the non-fma versions?
Chris@19 152 Q2.7 Which language is FFTW written in?
Chris@19 153 Q2.8 Can I call FFTW from Fortran?
Chris@19 154 Q2.9 Can I call FFTW from C++?
Chris@19 155 Q2.10 Why isn't FFTW written in Fortran/C++?
Chris@19 156 Q2.11 How do I compile FFTW to run in single precision?
Chris@19 157 Q2.12 --enable-k7 does not work on x86-64
Chris@19 158
Chris@19 159 -------------------------------------------------------------------------------
Chris@19 160
Chris@19 161 Question 2.1. Which systems does FFTW run on?
Chris@19 162
Chris@19 163 FFTW is written in ANSI C, and should work on any system with a decent C
Chris@19 164 compiler. (See also Q2.2 `Does FFTW run on Windows?', Q2.3 `My compiler
Chris@19 165 has trouble with FFTW.'.) FFTW can also take advantage of certain
Chris@19 166 hardware-specific features, such as cycle counters and SIMD instructions,
Chris@19 167 but this is optional.
Chris@19 168
Chris@19 169 -------------------------------------------------------------------------------
Chris@19 170
Chris@19 171 Question 2.2. Does FFTW run on Windows?
Chris@19 172
Chris@19 173 Yes, many people have reported successfully using FFTW on Windows with
Chris@19 174 various compilers. FFTW was not developed on Windows, but the source code
Chris@19 175 is essentially straight ANSI C. See also the FFTW Windows installation
Chris@19 176 notes, Q2.3 `My compiler has trouble with FFTW.', and Q3.18 `How do I call
Chris@19 177 FFTW from the Microsoft language du jour?'.
Chris@19 178
Chris@19 179 -------------------------------------------------------------------------------
Chris@19 180
Chris@19 181 Question 2.3. My compiler has trouble with FFTW.
Chris@19 182
Chris@19 183 Complain fiercely to the vendor of the compiler.
Chris@19 184
Chris@19 185 We have successfully used gcc 3.2.x on x86 and PPC, a recent Compaq C
Chris@19 186 compiler for Alpha, version 6 of IBM's xlc compiler for AIX, Intel's icc
Chris@19 187 versions 5-7, and Sun WorkShop cc version 6.
Chris@19 188
Chris@19 189 FFTW is likely to push compilers to their limits, however, and several
Chris@19 190 compiler bugs have been exposed by FFTW. A partial list follows.
Chris@19 191
Chris@19 192 gcc 2.95.x for Solaris/SPARC produces incorrect code for the test program
Chris@19 193 (workaround: recompile the libbench2 directory with -O2).
Chris@19 194
Chris@19 195 NetBSD/macppc 1.6 comes with a gcc version that also miscompiles the test
Chris@19 196 program. (Please report a workaround if you know one.)
Chris@19 197
Chris@19 198 gcc 3.2.3 for ARM reportedly crashes during compilation. This bug is
Chris@19 199 reportedly fixed in later versions of gcc.
Chris@19 200
Chris@19 201 Versions 8.0 and 8.1 of Intel's icc falsely claim to be gcc, so you should
Chris@19 202 specify CC="icc -no-gcc"; this is automatic in FFTW 3.1. icc-8.0.066
Chris@19 203 reportely produces incorrect code for FFTW 2.1.5, but is fixed in version
Chris@19 204 8.1. icc-7.1 compiler build 20030402Z appears to produce incorrect
Chris@19 205 dependencies, causing the compilation to fail. icc-7.1 build 20030307Z
Chris@19 206 appears to work fine. (Use icc -V to check which build you have.) As of
Chris@19 207 2003/04/18, build 20030402Z appears not to be available any longer on
Chris@19 208 Intel's website, whereas the older build 20030307Z is available.
Chris@19 209
Chris@19 210 ranlib of GNU binutils 2.9.1 on Irix has been observed to corrupt the FFTW
Chris@19 211 libraries, causing a link failure when FFTW is compiled. Since ranlib is
Chris@19 212 completely superfluous on Irix, we suggest deleting it from your system
Chris@19 213 and replacing it with a symbolic link to /bin/echo.
Chris@19 214
Chris@19 215 If support for SIMD instructions is enabled in FFTW, further compiler
Chris@19 216 problems may appear:
Chris@19 217
Chris@19 218 gcc 3.4.[0123] for x86 produces incorrect SSE2 code for FFTW when -O2 (the
Chris@19 219 best choice for FFTW) is used, causing FFTW to crash (make check crashes).
Chris@19 220 This bug is fixed in gcc 3.4.4. On x86_64 (amd64/em64t), gcc 3.4.4
Chris@19 221 reportedly still has a similar problem, but this is fixed as of gcc 3.4.6.
Chris@19 222
Chris@19 223 gcc-3.2 for x86 produces incorrect SIMD code if -O3 is used. The same
Chris@19 224 compiler produces incorrect SIMD code if no optimization is used, too.
Chris@19 225 When using gcc-3.2, it is a good idea not to change the default CFLAGS
Chris@19 226 selected by the configure script.
Chris@19 227
Chris@19 228 Some 3.0.x and 3.1.x versions of gcc on x86 may crash. gcc so-called 2.96
Chris@19 229 shipping with RedHat 7.3 crashes when compiling SIMD code. In both cases,
Chris@19 230 please upgrade to gcc-3.2 or later.
Chris@19 231
Chris@19 232 Intel's icc 6.0 misaligns SSE constants, but FFTW has a workaround. icc
Chris@19 233 8.x fails to compile FFTW 3.0.x because it falsely claims to be gcc; we
Chris@19 234 believe this to be a bug in icc, but FFTW 3.1 has a workaround.
Chris@19 235
Chris@19 236 Visual C++ 2003 reportedly produces incorrect code for SSE/SSE2 when
Chris@19 237 compiling FFTW. This bug was reportedly fixed in VC++ 2005;
Chris@19 238 alternatively, you could switch to the Intel compiler. VC++ 6.0 also
Chris@19 239 reportedly produces incorrect code for the file reodft11e-r2hc-odd.c
Chris@19 240 unless optimizations are disabled for that file.
Chris@19 241
Chris@19 242 gcc 2.95 on MacOS X miscompiles AltiVec code (fixed in later versions).
Chris@19 243 gcc 3.2.x miscompiles AltiVec permutations, but FFTW has a workaround.
Chris@19 244 gcc 4.0.1 on MacOS for Intel crashes when compiling FFTW; a workaround is
Chris@19 245 to compile one file without optimization: cd kernel; make CFLAGS=" "
Chris@19 246 trig.lo.
Chris@19 247
Chris@19 248 gcc 4.1.1 reportedly crashes when compiling FFTW for MIPS; the workaround
Chris@19 249 is to compile the file it crashes on (t2_64.c) with a lower optimization
Chris@19 250 level.
Chris@19 251
Chris@19 252 gcc versions 4.1.2 to 4.2.0 for x86 reportedly miscompile FFTW 3.1's test
Chris@19 253 program, causing make check to crash (gcc bug #26528). The bug was
Chris@19 254 reportedly fixed in gcc version 4.2.1 and later. A workaround is to
Chris@19 255 compile libbench2/verify-lib.c without optimization.
Chris@19 256
Chris@19 257 -------------------------------------------------------------------------------
Chris@19 258
Chris@19 259 Question 2.4. FFTW does not compile on Solaris, complaining about const.
Chris@19 260
Chris@19 261 We know that at least on Solaris 2.5.x with Sun's compilers 4.2 you might
Chris@19 262 get error messages from make such as
Chris@19 263
Chris@19 264 "./fftw.h", line 88: warning: const is a keyword in ANSI C
Chris@19 265
Chris@19 266 This is the case when the configure script reports that const does not
Chris@19 267 work:
Chris@19 268
Chris@19 269 checking for working const... (cached) no
Chris@19 270
Chris@19 271 You should be aware that Solaris comes with two compilers, namely,
Chris@19 272 /opt/SUNWspro/SC4.2/bin/cc and /usr/ucb/cc. The latter compiler is
Chris@19 273 non-ANSI. Indeed, it is a perverse shell script that calls the real
Chris@19 274 compiler in non-ANSI mode. In order to compile FFTW, change your path so
Chris@19 275 that the right cc is used.
Chris@19 276
Chris@19 277 To know whether your compiler is the right one, type cc -V. If the
Chris@19 278 compiler prints ``ucbcc'', as in
Chris@19 279
Chris@19 280 ucbcc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2
Chris@19 281
Chris@19 282 then the compiler is wrong. The right message is something like
Chris@19 283
Chris@19 284 cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2
Chris@19 285
Chris@19 286 -------------------------------------------------------------------------------
Chris@19 287
Chris@19 288 Question 2.5. What's the difference between --enable-3dnow and --enable-k7?
Chris@19 289
Chris@19 290 --enable-k7 enables 3DNow! instructions on K7 processors (AMD Athlon and
Chris@19 291 its variants). K7 support is provided by assembly routines generated by a
Chris@19 292 special purpose compiler. As of fftw-3.2, --enable-k7 is no longer
Chris@19 293 supported.
Chris@19 294
Chris@19 295 --enable-3dnow enables generic 3DNow! support using gcc builtin functions.
Chris@19 296 This works on earlier AMD processors, but it is not as fast as our special
Chris@19 297 assembly routines. As of fftw-3.1, --enable-3dnow is no longer supported.
Chris@19 298
Chris@19 299 -------------------------------------------------------------------------------
Chris@19 300
Chris@19 301 Question 2.6. What's the difference between the fma and the non-fma versions?
Chris@19 302
Chris@19 303 The fma version tries to exploit the fused multiply-add instructions
Chris@19 304 implemented in many processors such as PowerPC, ia-64, and MIPS. The two
Chris@19 305 FFTW packages are otherwise identical. In FFTW 3.1, the fma and non-fma
Chris@19 306 versions were merged together into a single package, and the configure
Chris@19 307 script attempts to automatically guess which version to use.
Chris@19 308
Chris@19 309 The FFTW 3.1 configure script enables fma by default on PowerPC, Itanium,
Chris@19 310 and PA-RISC, and disables it otherwise. You can force one or the other by
Chris@19 311 using the --enable-fma or --disable-fma flag for configure.
Chris@19 312
Chris@19 313 Definitely use fma if you have a PowerPC-based system with gcc (or IBM
Chris@19 314 xlc). This includes all GNU/Linux systems for PowerPC and the older
Chris@19 315 PowerPC-based MacOS systems. Also use it on PA-RISC and Itanium with the
Chris@19 316 HP/UX compiler.
Chris@19 317
Chris@19 318 Definitely do not use the fma version if you have an ia-32 processor
Chris@19 319 (Intel, AMD, MacOS on Intel, etcetera).
Chris@19 320
Chris@19 321 For other architectures/compilers, the situation is not so clear. For
Chris@19 322 example, ia-64 has the fma instruction, but gcc-3.2 appears not to exploit
Chris@19 323 it correctly. Other compilers may do the right thing, but we have not
Chris@19 324 tried them. Please send us your feedback so that we can update this FAQ
Chris@19 325 entry.
Chris@19 326
Chris@19 327 -------------------------------------------------------------------------------
Chris@19 328
Chris@19 329 Question 2.7. Which language is FFTW written in?
Chris@19 330
Chris@19 331 FFTW is written in ANSI C. Most of the code, however, was automatically
Chris@19 332 generated by a program called genfft, written in the Objective Caml
Chris@19 333 dialect of ML. You do not need to know ML or to have an Objective Caml
Chris@19 334 compiler in order to use FFTW.
Chris@19 335
Chris@19 336 genfft is provided with the FFTW sources, which means that you can play
Chris@19 337 with the code generator if you want. In this case, you need a working
Chris@19 338 Objective Caml system. Objective Caml is available from the Caml web
Chris@19 339 page.
Chris@19 340
Chris@19 341 -------------------------------------------------------------------------------
Chris@19 342
Chris@19 343 Question 2.8. Can I call FFTW from Fortran?
Chris@19 344
Chris@19 345 Yes, FFTW (versions 1.3 and higher) contains a Fortran-callable interface,
Chris@19 346 documented in the FFTW manual.
Chris@19 347
Chris@19 348 By default, FFTW configures its Fortran interface to work with the first
Chris@19 349 compiler it finds, e.g. g77. To configure for a different, incompatible
Chris@19 350 Fortran compiler foobar, use ./configure F77=foobar when installing FFTW.
Chris@19 351 (In the case of g77, however, FFTW 3.x also includes an extra set of
Chris@19 352 Fortran-callable routines with one less underscore at the end of
Chris@19 353 identifiers, which should cover most other Fortran compilers on Linux at
Chris@19 354 least.)
Chris@19 355
Chris@19 356 -------------------------------------------------------------------------------
Chris@19 357
Chris@19 358 Question 2.9. Can I call FFTW from C++?
Chris@19 359
Chris@19 360 Most definitely. FFTW should compile and/or link under any C++ compiler.
Chris@19 361 Moreover, it is likely that the C++ <complex> template class is
Chris@19 362 bit-compatible with FFTW's complex-number format (see the FFTW manual for
Chris@19 363 more details).
Chris@19 364
Chris@19 365 -------------------------------------------------------------------------------
Chris@19 366
Chris@19 367 Question 2.10. Why isn't FFTW written in Fortran/C++?
Chris@19 368
Chris@19 369 Because we don't like those languages, and neither approaches the
Chris@19 370 portability of C.
Chris@19 371
Chris@19 372 -------------------------------------------------------------------------------
Chris@19 373
Chris@19 374 Question 2.11. How do I compile FFTW to run in single precision?
Chris@19 375
Chris@19 376 On a Unix system: configure --enable-float. On a non-Unix system: edit
Chris@19 377 config.h to #define the symbol FFTW_SINGLE (for FFTW 3.x). In both cases,
Chris@19 378 you must then recompile FFTW. In FFTW 3, all FFTW identifiers will then
Chris@19 379 begin with fftwf_ instead of fftw_.
Chris@19 380
Chris@19 381 -------------------------------------------------------------------------------
Chris@19 382
Chris@19 383 Question 2.12. --enable-k7 does not work on x86-64
Chris@19 384
Chris@19 385 Support for --enable-k7 was discontinued in fftw-3.2.
Chris@19 386
Chris@19 387 The fftw-3.1 release supports --enable-k7. This option only works on
Chris@19 388 32-bit x86 machines that implement 3DNow!, including the AMD Athlon and
Chris@19 389 the AMD Opteron in 32-bit mode. --enable-k7 does not work on AMD Opteron
Chris@19 390 in 64-bit mode. Use --enable-sse for x86-64 machines.
Chris@19 391
Chris@19 392 FFTW supports 3DNow! by means of assembly code generated by a
Chris@19 393 special-purpose compiler. It is hard to produce assembly code that works
Chris@19 394 in both 32-bit and 64-bit mode.
Chris@19 395
Chris@19 396 ===============================================================================
Chris@19 397
Chris@19 398 Section 3. Using FFTW
Chris@19 399
Chris@19 400 Q3.1 Why not support the FFTW 2 interface in FFTW 3?
Chris@19 401 Q3.2 Why do FFTW 3 plans encapsulate the input/output arrays and not ju
Chris@19 402 Q3.3 FFTW seems really slow.
Chris@19 403 Q3.4 FFTW slows down after repeated calls.
Chris@19 404 Q3.5 An FFTW routine is crashing when I call it.
Chris@19 405 Q3.6 My Fortran program crashes when calling FFTW.
Chris@19 406 Q3.7 FFTW gives results different from my old FFT.
Chris@19 407 Q3.8 FFTW gives different results between runs
Chris@19 408 Q3.9 Can I save FFTW's plans?
Chris@19 409 Q3.10 Why does your inverse transform return a scaled result?
Chris@19 410 Q3.11 How can I make FFTW put the origin (zero frequency) at the center
Chris@19 411 Q3.12 How do I FFT an image/audio file in *foobar* format?
Chris@19 412 Q3.13 My program does not link (on Unix).
Chris@19 413 Q3.14 I included your header, but linking still fails.
Chris@19 414 Q3.15 My program crashes, complaining about stack space.
Chris@19 415 Q3.16 FFTW seems to have a memory leak.
Chris@19 416 Q3.17 The output of FFTW's transform is all zeros.
Chris@19 417 Q3.18 How do I call FFTW from the Microsoft language du jour?
Chris@19 418 Q3.19 Can I compute only a subset of the DFT outputs?
Chris@19 419 Q3.20 Can I use FFTW's routines for in-place and out-of-place matrix tra
Chris@19 420
Chris@19 421 -------------------------------------------------------------------------------
Chris@19 422
Chris@19 423 Question 3.1. Why not support the FFTW 2 interface in FFTW 3?
Chris@19 424
Chris@19 425 FFTW 3 has semantics incompatible with earlier versions: its plans can
Chris@19 426 only be used for a given stride, multiplicity, and other characteristics
Chris@19 427 of the input and output arrays; these stronger semantics are necessary for
Chris@19 428 performance reasons. Thus, it is impossible to efficiently emulate the
Chris@19 429 older interface (whose plans can be used for any transform of the same
Chris@19 430 size). We believe that it should be possible to upgrade most programs
Chris@19 431 without any difficulty, however.
Chris@19 432
Chris@19 433 -------------------------------------------------------------------------------
Chris@19 434
Chris@19 435 Question 3.2. Why do FFTW 3 plans encapsulate the input/output arrays and not just the algorithm?
Chris@19 436
Chris@19 437 There are several reasons:
Chris@19 438
Chris@19 439 * It was important for performance reasons that the plan be specific to
Chris@19 440 array characteristics like the stride (and alignment, for SIMD), and
Chris@19 441 requiring that the user maintain these invariants is error prone.
Chris@19 442 * In most high-performance applications, as far as we can tell, you are
Chris@19 443 usually transforming the same array over and over, so FFTW's semantics
Chris@19 444 should not be a burden.
Chris@19 445 * If you need to transform another array of the same size, creating a new
Chris@19 446 plan once the first exists is a cheap operation.
Chris@19 447 * If you need to transform many arrays of the same size at once, you
Chris@19 448 should really use the plan_many routines in FFTW's "advanced" interface.
Chris@19 449 * If the abovementioned array characteristics are the same, you are
Chris@19 450 willing to pay close attention to the documentation, and you really need
Chris@19 451 to, we provide a "new-array execution" interface to apply a plan to a
Chris@19 452 new array.
Chris@19 453
Chris@19 454 -------------------------------------------------------------------------------
Chris@19 455
Chris@19 456 Question 3.3. FFTW seems really slow.
Chris@19 457
Chris@19 458 You are probably recreating the plan before every transform, rather than
Chris@19 459 creating it once and reusing it for all transforms of the same size. FFTW
Chris@19 460 is designed to be used in the following way:
Chris@19 461
Chris@19 462 * First, you create a plan. This will take several seconds.
Chris@19 463 * Then, you reuse the plan many times to perform FFTs. These are fast.
Chris@19 464
Chris@19 465 If you don't need to compute many transforms and the time for the planner
Chris@19 466 is significant, you have two options. First, you can use the
Chris@19 467 FFTW_ESTIMATE option in the planner, which uses heuristics instead of
Chris@19 468 runtime measurements and produces a good plan in a short time. Second,
Chris@19 469 you can use the wisdom feature to precompute the plan; see Q3.9 `Can I
Chris@19 470 save FFTW's plans?'
Chris@19 471
Chris@19 472 -------------------------------------------------------------------------------
Chris@19 473
Chris@19 474 Question 3.4. FFTW slows down after repeated calls.
Chris@19 475
Chris@19 476 Probably, NaNs or similar are creeping into your data, and the slowdown is
Chris@19 477 due to the resulting floating-point exceptions. For example, be aware
Chris@19 478 that repeatedly FFTing the same array is a diverging process (because FFTW
Chris@19 479 computes the unnormalized transform).
Chris@19 480
Chris@19 481 -------------------------------------------------------------------------------
Chris@19 482
Chris@19 483 Question 3.5. An FFTW routine is crashing when I call it.
Chris@19 484
Chris@19 485 Did the FFTW test programs pass (make check, or cd tests; make bigcheck if
Chris@19 486 you want to be paranoid)? If so, you almost certainly have a bug in your
Chris@19 487 own code. For example, you could be passing invalid arguments (such as
Chris@19 488 wrongly-sized arrays) to FFTW, or you could simply have memory corruption
Chris@19 489 elsewhere in your program that causes random crashes later on. Please
Chris@19 490 don't complain to us unless you can come up with a minimal self-contained
Chris@19 491 program (preferably under 30 lines) that illustrates the problem.
Chris@19 492
Chris@19 493 -------------------------------------------------------------------------------
Chris@19 494
Chris@19 495 Question 3.6. My Fortran program crashes when calling FFTW.
Chris@19 496
Chris@19 497 As described in the manual, on 64-bit machines you must store the plans in
Chris@19 498 variables large enough to hold a pointer, for example integer*8. We
Chris@19 499 recommend using integer*8 on 32-bit machines as well, to simplify porting.
Chris@19 500
Chris@19 501 -------------------------------------------------------------------------------
Chris@19 502
Chris@19 503 Question 3.7. FFTW gives results different from my old FFT.
Chris@19 504
Chris@19 505 People follow many different conventions for the DFT, and you should be
Chris@19 506 sure to know the ones that we use (described in the FFTW manual). In
Chris@19 507 particular, you should be aware that the FFTW_FORWARD/FFTW_BACKWARD
Chris@19 508 directions correspond to signs of -1/+1 in the exponent of the DFT
Chris@19 509 definition. (*Numerical Recipes* uses the opposite convention.)
Chris@19 510
Chris@19 511 You should also know that we compute an unnormalized transform. In
Chris@19 512 contrast, Matlab is an example of program that computes a normalized
Chris@19 513 transform. See Q3.10 `Why does your inverse transform return a scaled
Chris@19 514 result?'.
Chris@19 515
Chris@19 516 Finally, note that floating-point arithmetic is not exact, so different
Chris@19 517 FFT algorithms will give slightly different results (on the order of the
Chris@19 518 numerical accuracy; typically a fractional difference of 1e-15 or so in
Chris@19 519 double precision).
Chris@19 520
Chris@19 521 -------------------------------------------------------------------------------
Chris@19 522
Chris@19 523 Question 3.8. FFTW gives different results between runs
Chris@19 524
Chris@19 525 If you use FFTW_MEASURE or FFTW_PATIENT mode, then the algorithm FFTW
Chris@19 526 employs is not deterministic: it depends on runtime performance
Chris@19 527 measurements. This will cause the results to vary slightly from run to
Chris@19 528 run. However, the differences should be slight, on the order of the
Chris@19 529 floating-point precision, and therefore should have no practical impact on
Chris@19 530 most applications.
Chris@19 531
Chris@19 532 If you use saved plans (wisdom) or FFTW_ESTIMATE mode, however, then the
Chris@19 533 algorithm is deterministic and the results should be identical between
Chris@19 534 runs.
Chris@19 535
Chris@19 536 -------------------------------------------------------------------------------
Chris@19 537
Chris@19 538 Question 3.9. Can I save FFTW's plans?
Chris@19 539
Chris@19 540 Yes. Starting with version 1.2, FFTW provides the wisdom mechanism for
Chris@19 541 saving plans; see the FFTW manual.
Chris@19 542
Chris@19 543 -------------------------------------------------------------------------------
Chris@19 544
Chris@19 545 Question 3.10. Why does your inverse transform return a scaled result?
Chris@19 546
Chris@19 547 Computing the forward transform followed by the backward transform (or
Chris@19 548 vice versa) yields the original array scaled by the size of the array.
Chris@19 549 (For multi-dimensional transforms, the size of the array is the product of
Chris@19 550 the dimensions.) We could, instead, have chosen a normalization that
Chris@19 551 would have returned the unscaled array. Or, to accomodate the many
Chris@19 552 conventions in this matter, the transform routines could have accepted a
Chris@19 553 "scale factor" parameter. We did not do this, however, for two reasons.
Chris@19 554 First, we didn't want to sacrifice performance in the common case where
Chris@19 555 the scale factor is 1. Second, in real applications the FFT is followed or
Chris@19 556 preceded by some computation on the data, into which the scale factor can
Chris@19 557 typically be absorbed at little or no cost.
Chris@19 558
Chris@19 559 -------------------------------------------------------------------------------
Chris@19 560
Chris@19 561 Question 3.11. How can I make FFTW put the origin (zero frequency) at the center of its output?
Chris@19 562
Chris@19 563 For human viewing of a spectrum, it is often convenient to put the origin
Chris@19 564 in frequency space at the center of the output array, rather than in the
Chris@19 565 zero-th element (the default in FFTW). If all of the dimensions of your
Chris@19 566 array are even, you can accomplish this by simply multiplying each element
Chris@19 567 of the input array by (-1)^(i + j + ...), where i, j, etcetera are the
Chris@19 568 indices of the element. (This trick is a general property of the DFT, and
Chris@19 569 is not specific to FFTW.)
Chris@19 570
Chris@19 571 -------------------------------------------------------------------------------
Chris@19 572
Chris@19 573 Question 3.12. How do I FFT an image/audio file in *foobar* format?
Chris@19 574
Chris@19 575 FFTW performs an FFT on an array of floating-point values. You can
Chris@19 576 certainly use it to compute the transform of an image or audio stream, but
Chris@19 577 you are responsible for figuring out your data format and converting it to
Chris@19 578 the form FFTW requires.
Chris@19 579
Chris@19 580 -------------------------------------------------------------------------------
Chris@19 581
Chris@19 582 Question 3.13. My program does not link (on Unix).
Chris@19 583
Chris@19 584 The libraries must be listed in the correct order (-lfftw3 -lm for FFTW
Chris@19 585 3.x) and *after* your program sources/objects. (The general rule is that
Chris@19 586 if *A* uses *B*, then *A* must be listed before *B* in the link command.).
Chris@19 587
Chris@19 588 -------------------------------------------------------------------------------
Chris@19 589
Chris@19 590 Question 3.14. I included your header, but linking still fails.
Chris@19 591
Chris@19 592 You're a C++ programmer, aren't you? You have to compile the FFTW library
Chris@19 593 and link it into your program, not just #include <fftw3.h>. (Yes, this is
Chris@19 594 really a FAQ.)
Chris@19 595
Chris@19 596 -------------------------------------------------------------------------------
Chris@19 597
Chris@19 598 Question 3.15. My program crashes, complaining about stack space.
Chris@19 599
Chris@19 600 You cannot declare large arrays with automatic storage (e.g. via
Chris@19 601 fftw_complex array[N]); you should use fftw_malloc (or equivalent) to
Chris@19 602 allocate the arrays you want to transform if they are larger than a few
Chris@19 603 hundred elements.
Chris@19 604
Chris@19 605 -------------------------------------------------------------------------------
Chris@19 606
Chris@19 607 Question 3.16. FFTW seems to have a memory leak.
Chris@19 608
Chris@19 609 After you create a plan, FFTW caches the information required to quickly
Chris@19 610 recreate the plan. (See Q3.9 `Can I save FFTW's plans?') It also
Chris@19 611 maintains a small amount of other persistent memory. You can deallocate
Chris@19 612 all of FFTW's internally allocated memory, if you wish, by calling
Chris@19 613 fftw_cleanup(), as documented in the manual.
Chris@19 614
Chris@19 615 -------------------------------------------------------------------------------
Chris@19 616
Chris@19 617 Question 3.17. The output of FFTW's transform is all zeros.
Chris@19 618
Chris@19 619 You should initialize your input array *after* creating the plan, unless
Chris@19 620 you use FFTW_ESTIMATE: planning with FFTW_MEASURE or FFTW_PATIENT
Chris@19 621 overwrites the input/output arrays, as described in the manual.
Chris@19 622
Chris@19 623 -------------------------------------------------------------------------------
Chris@19 624
Chris@19 625 Question 3.18. How do I call FFTW from the Microsoft language du jour?
Chris@19 626
Chris@19 627 Please *do not* ask us Windows-specific questions. We do not use Windows.
Chris@19 628 We know nothing about Visual Basic, Visual C++, or .NET. Please find the
Chris@19 629 appropriate Usenet discussion group and ask your question there. See also
Chris@19 630 Q2.2 `Does FFTW run on Windows?'.
Chris@19 631
Chris@19 632 -------------------------------------------------------------------------------
Chris@19 633
Chris@19 634 Question 3.19. Can I compute only a subset of the DFT outputs?
Chris@19 635
Chris@19 636 In general, no, an FFT intrinsically computes all outputs from all inputs.
Chris@19 637 In principle, there is something called a *pruned FFT* that can do what
Chris@19 638 you want, but to compute K outputs out of N the complexity is in general
Chris@19 639 O(N log K) instead of O(N log N), thus saving only a small additive factor
Chris@19 640 in the log. (The same argument holds if you instead have only K nonzero
Chris@19 641 inputs.)
Chris@19 642
Chris@19 643 There are some specific cases in which you can get the O(N log K)
Chris@19 644 performance benefits easily, however, by combining a few ordinary FFTs.
Chris@19 645 In particular, the case where you want the first K outputs, where K
Chris@19 646 divides N, can be handled by performing N/K transforms of size K and then
Chris@19 647 summing the outputs multiplied by appropriate phase factors. For more
Chris@19 648 details, see pruned FFTs with FFTW.
Chris@19 649
Chris@19 650 There are also some algorithms that compute pruned transforms
Chris@19 651 *approximately*, but they are beyond the scope of this FAQ.
Chris@19 652
Chris@19 653 -------------------------------------------------------------------------------
Chris@19 654
Chris@19 655 Question 3.20. Can I use FFTW's routines for in-place and out-of-place matrix transposition?
Chris@19 656
Chris@19 657 You can use the FFTW guru interface to create a rank-0 transform of vector
Chris@19 658 rank 2 where the vector strides are transposed. (A rank-0 transform is
Chris@19 659 equivalent to a 1D transform of size 1, which. just copies the input into
Chris@19 660 the output.) Specifying the same location for the input and output makes
Chris@19 661 the transpose in-place.
Chris@19 662
Chris@19 663 For double-valued data stored in row-major format, plan creation looks
Chris@19 664 like this:
Chris@19 665
Chris@19 666 fftw_plan plan_transpose(int rows, int cols, double *in, double *out)
Chris@19 667 {
Chris@19 668 const unsigned flags = FFTW_ESTIMATE; /* other flags are possible */
Chris@19 669 fftw_iodim howmany_dims[2];
Chris@19 670
Chris@19 671 howmany_dims[0].n = rows;
Chris@19 672 howmany_dims[0].is = cols;
Chris@19 673 howmany_dims[0].os = 1;
Chris@19 674
Chris@19 675 howmany_dims[1].n = cols;
Chris@19 676 howmany_dims[1].is = 1;
Chris@19 677 howmany_dims[1].os = rows;
Chris@19 678
Chris@19 679 return fftw_plan_guru_r2r(/*rank=*/ 0, /*dims=*/ NULL,
Chris@19 680 /*howmany_rank=*/ 2, howmany_dims,
Chris@19 681 in, out, /*kind=*/ NULL, flags);
Chris@19 682 }
Chris@19 683 (This entry was written by Rhys Ulerich.)
Chris@19 684
Chris@19 685 ===============================================================================
Chris@19 686
Chris@19 687 Section 4. Internals of FFTW
Chris@19 688
Chris@19 689 Q4.1 How does FFTW work?
Chris@19 690 Q4.2 Why is FFTW so fast?
Chris@19 691
Chris@19 692 -------------------------------------------------------------------------------
Chris@19 693
Chris@19 694 Question 4.1. How does FFTW work?
Chris@19 695
Chris@19 696 The innovation (if it can be so called) in FFTW consists in having a
Chris@19 697 variety of composable *solvers*, representing different FFT algorithms and
Chris@19 698 implementation strategies, whose combination into a particular *plan* for
Chris@19 699 a given size can be determined at runtime according to the characteristics
Chris@19 700 of your machine/compiler. This peculiar software architecture allows FFTW
Chris@19 701 to adapt itself to almost any machine.
Chris@19 702
Chris@19 703 For more details (albeit somewhat outdated), see the paper "FFTW: An
Chris@19 704 Adaptive Software Architecture for the FFT", by M. Frigo and S. G.
Chris@19 705 Johnson, *Proc. ICASSP* 3, 1381 (1998), also available at the FFTW web
Chris@19 706 page.
Chris@19 707
Chris@19 708 -------------------------------------------------------------------------------
Chris@19 709
Chris@19 710 Question 4.2. Why is FFTW so fast?
Chris@19 711
Chris@19 712 This is a complex question, and there is no simple answer. In fact, the
Chris@19 713 authors do not fully know the answer, either. In addition to many small
Chris@19 714 performance hacks throughout FFTW, there are three general reasons for
Chris@19 715 FFTW's speed.
Chris@19 716
Chris@19 717 * FFTW uses a variety of FFT algorithms and implementation styles that
Chris@19 718 can be arbitrarily composed to adapt itself to a machine. See Q4.1 `How
Chris@19 719 does FFTW work?'.
Chris@19 720 * FFTW uses a code generator to produce highly-optimized routines for
Chris@19 721 computing small transforms.
Chris@19 722 * FFTW uses explicit divide-and-conquer to take advantage of the memory
Chris@19 723 hierarchy.
Chris@19 724
Chris@19 725 For more details (albeit somewhat outdated), see the paper "FFTW: An
Chris@19 726 Adaptive Software Architecture for the FFT", by M. Frigo and S. G.
Chris@19 727 Johnson, *Proc. ICASSP* 3, 1381 (1998), available along with other
Chris@19 728 references at the FFTW web page.
Chris@19 729
Chris@19 730 ===============================================================================
Chris@19 731
Chris@19 732 Section 5. Known bugs
Chris@19 733
Chris@19 734 Q5.1 FFTW 1.1 crashes in rfftwnd on Linux.
Chris@19 735 Q5.2 The MPI transforms in FFTW 1.2 give incorrect results/leak memory.
Chris@19 736 Q5.3 The test programs in FFTW 1.2.1 fail when I change FFTW to use sin
Chris@19 737 Q5.4 The test program in FFTW 1.2.1 fails for n > 46340.
Chris@19 738 Q5.5 The threaded code fails on Linux Redhat 5.0
Chris@19 739 Q5.6 FFTW 2.0's rfftwnd fails for rank > 1 transforms with a final dime
Chris@19 740 Q5.7 FFTW 2.0's complex transforms give the wrong results with prime fa
Chris@19 741 Q5.8 FFTW 2.1.1's MPI test programs crash with MPICH.
Chris@19 742 Q5.9 FFTW 2.1.2's multi-threaded transforms don't work on AIX.
Chris@19 743 Q5.10 FFTW 2.1.2's complex transforms give incorrect results for large p
Chris@19 744 Q5.11 FFTW 2.1.3's multi-threaded transforms don't give any speedup on S
Chris@19 745 Q5.12 FFTW 2.1.3 crashes on AIX.
Chris@19 746
Chris@19 747 -------------------------------------------------------------------------------
Chris@19 748
Chris@19 749 Question 5.1. FFTW 1.1 crashes in rfftwnd on Linux.
Chris@19 750
Chris@19 751 This bug was fixed in FFTW 1.2. There was a bug in rfftwnd causing an
Chris@19 752 incorrect amount of memory to be allocated. The bug showed up in Linux
Chris@19 753 with libc-5.3.12 (and nowhere else that we know of).
Chris@19 754
Chris@19 755 -------------------------------------------------------------------------------
Chris@19 756
Chris@19 757 Question 5.2. The MPI transforms in FFTW 1.2 give incorrect results/leak memory.
Chris@19 758
Chris@19 759 These bugs were corrected in FFTW 1.2.1. The MPI transforms (really, just
Chris@19 760 the transpose routines) in FFTW 1.2 had bugs that could cause errors in
Chris@19 761 some situations.
Chris@19 762
Chris@19 763 -------------------------------------------------------------------------------
Chris@19 764
Chris@19 765 Question 5.3. The test programs in FFTW 1.2.1 fail when I change FFTW to use single precision.
Chris@19 766
Chris@19 767 This bug was fixed in FFTW 1.3. (Older versions of FFTW did work in
Chris@19 768 single precision, but the test programs didn't--the error tolerances in
Chris@19 769 the tests were set for double precision.)
Chris@19 770
Chris@19 771 -------------------------------------------------------------------------------
Chris@19 772
Chris@19 773 Question 5.4. The test program in FFTW 1.2.1 fails for n > 46340.
Chris@19 774
Chris@19 775 This bug was fixed in FFTW 1.3. FFTW 1.2.1 produced the right answer, but
Chris@19 776 the test program was wrong. For large n, n*n in the naive transform that
Chris@19 777 we used for comparison overflows 32 bit integer precision, breaking the
Chris@19 778 test.
Chris@19 779
Chris@19 780 -------------------------------------------------------------------------------
Chris@19 781
Chris@19 782 Question 5.5. The threaded code fails on Linux Redhat 5.0
Chris@19 783
Chris@19 784 We had problems with glibc-2.0.5. The code should work with glibc-2.0.7.
Chris@19 785
Chris@19 786 -------------------------------------------------------------------------------
Chris@19 787
Chris@19 788 Question 5.6. FFTW 2.0's rfftwnd fails for rank > 1 transforms with a final dimension >= 65536.
Chris@19 789
Chris@19 790 This bug was fixed in FFTW 2.0.1. (There was a 32-bit integer overflow
Chris@19 791 due to a poorly-parenthesized expression.)
Chris@19 792
Chris@19 793 -------------------------------------------------------------------------------
Chris@19 794
Chris@19 795 Question 5.7. FFTW 2.0's complex transforms give the wrong results with prime factors 17 to 97.
Chris@19 796
Chris@19 797 There was a bug in the complex transforms that could cause incorrect
Chris@19 798 results under (hopefully rare) circumstances for lengths with
Chris@19 799 intermediate-size prime factors (17-97). This bug was fixed in FFTW
Chris@19 800 2.1.1.
Chris@19 801
Chris@19 802 -------------------------------------------------------------------------------
Chris@19 803
Chris@19 804 Question 5.8. FFTW 2.1.1's MPI test programs crash with MPICH.
Chris@19 805
Chris@19 806 This bug was fixed in FFTW 2.1.2. The 2.1/2.1.1 MPI test programs crashed
Chris@19 807 when using the MPICH implementation of MPI with the ch_p4 device (TCP/IP);
Chris@19 808 the transforms themselves worked fine.
Chris@19 809
Chris@19 810 -------------------------------------------------------------------------------
Chris@19 811
Chris@19 812 Question 5.9. FFTW 2.1.2's multi-threaded transforms don't work on AIX.
Chris@19 813
Chris@19 814 This bug was fixed in FFTW 2.1.3. The multi-threaded transforms in
Chris@19 815 previous versions didn't work with AIX's pthreads implementation, which
Chris@19 816 idiosyncratically creates threads in detached (non-joinable) mode by
Chris@19 817 default.
Chris@19 818
Chris@19 819 -------------------------------------------------------------------------------
Chris@19 820
Chris@19 821 Question 5.10. FFTW 2.1.2's complex transforms give incorrect results for large prime sizes.
Chris@19 822
Chris@19 823 This bug was fixed in FFTW 2.1.3. FFTW's complex-transform algorithm for
Chris@19 824 prime sizes (in versions 2.0 to 2.1.2) had an integer overflow problem
Chris@19 825 that caused incorrect results for many primes greater than 32768 (on
Chris@19 826 32-bit machines). (Sizes without large prime factors are not affected.)
Chris@19 827
Chris@19 828 -------------------------------------------------------------------------------
Chris@19 829
Chris@19 830 Question 5.11. FFTW 2.1.3's multi-threaded transforms don't give any speedup on Solaris.
Chris@19 831
Chris@19 832 This bug was fixed in FFTW 2.1.4. (By default, Solaris creates threads
Chris@19 833 that do not parallelize over multiple processors, so one has to request
Chris@19 834 the proper behavior specifically.)
Chris@19 835
Chris@19 836 -------------------------------------------------------------------------------
Chris@19 837
Chris@19 838 Question 5.12. FFTW 2.1.3 crashes on AIX.
Chris@19 839
Chris@19 840 The FFTW 2.1.3 configure script picked incorrect compiler flags for the
Chris@19 841 xlc compiler on newer IBM processors. This is fixed in FFTW 2.1.4.
Chris@19 842