RFC: rewritten FFTW interface

[stevengj]

This patch rewrites the FFTW interface as discussed in issues #1617, #1806, and #1805.

The fft(x) function now performs a multidimensional FFT by default (what used to be called fftn). To transform along 0 or more dimensions, do fft(x, region) where region is an iterable set of integers. (Similarly for bfft, ifft, rfft, etcetera.) The functions fftn, fft2, and fft3 are removed.

It also adds a new function p = plan_fft(x) which returns a function p(x) that computes optimized FFTs of a fixed size. plan_fft has optional arguments to specify the region and FFTW planner flags.

It also adds in-place functions fft! etcetera. Subarrays are now supported too.

There are a few other odds and ends that I changed. e.g. FFTW.import_wisdom and FFTW.export_wisdom now import/export both single and double precision wisdom from/to a single file. The FFTW.num_threads function should now work properly even if fft has been previously called. brfft no longer overwrites its input. The 64-bit API is used everywhere. The fft.jl tests are a bit more extensive.

The documentation has not been updated yet; I wanted to get some feedback first. UPDATE: Documentation added.

[JeffBezanson]

This looks awesome! Very exciting to have this. Thanks.

[ViralBShah]

This is awesome.

Couple of comments. The tests can start passing, once you replace the use of ifft2 and ifft2 in extras/image.jl.

[ViralBShah]

Oops - I see you have already fixed the image.jl - I was looking at the commits in wrong order.

[ViralBShah]

The travis build has passed for both gcc and clang after the last commit, but it is showing yellow on github. Perhaps a travis bug? @staticfloat any ideas?

Looks good to merge otherwise.

[Keno]

Showing green for me!

[stevengj]

Thanks! Probably should wait to merge until I update the documentation. I also noticed a bug in the treatment of subarrays that I should fix, and add a test case for. I should have an updated patch in a couple of days.

[ViralBShah]

@loladiro It is not showing green here - https://github.com/JuliaLang/julia/pull/1856/commits

[Keno]

Hmm, interesting seems like a github bug though, since it shows up correctly in the "Discussion" section for me!

[ViralBShah]

In scale! there is a typo on line 407. It should be X instead of x.

[ViralBShah]

I am copying these scale! functions into linalg.jl for use in norm, so may be best to remove them from here.

[stevengj]

Yes, I noticed that. Also, it should return X.

[stevengj]

Added documentation, bugfixes, etcetera. Should hopefully be good to merge.

One thing I observed: plan execution seems to have an overhead of 30-50us compared to C, which is very noticeable for transforms of small sizes (especially <= 1000 or so). Deleting the assert_applicable argument check does not decrease this significantly. Is there some reason why the ccall overhead would be so high? Or is there some large overhead to calling anonymous functions? @JeffBezanson?