

The faster-than-fast Fourier transform - pmikal
http://web.mit.edu/newsoffice/2012/faster-fourier-transforms-0118.html

======
pygy_
Today's pedantic minute is sponsored by Carl Friedrich Gauss.

The FFT algorithm was _re_ discovered in the 60's. Gauss discovered it in the
early 19th century while studying the phase of the moon, before Fourier
described his transform. He published it in latin, and the text was lost until
1984.

~~~
dmarquis
Not to detract from Gauss' remarkable discovery but there is no relation
between Gauss' FFT algorithm and the continuous Fourier transform that Fourier
discovered. It is also worth mentioning that credit for the discrete Fourier
transform goes to Vandermode and pre-dates Gauss' FFT algorithm by about 30
years.

~~~
pygy_
I didn't know about Vandermonde, its always nice to learn something.

I'm no mathematician, and my understanding of the subject is limited. How is
the discrete Fourier transform unrelated to its continuous counterpart? Their
definitions are extremely similar...

From a semantic point of view, it is nice that all these transform bear the
same name, but historically, it is a bit unfair to attribute Fourier analysis
to Fourier, who didn't discover it (even though he greatly developed the
subject).

I know there's an eponymous law that describes this phenomenon, and it is of
course not named after its inventor, but I can't remember its name.

~~~
jasondavies
<http://en.wikipedia.org/wiki/Stiglers_law_of_eponymy>

~~~
wglb
I wonder if HN clipped the quote in that url. Let's try this:
<http://en.wikipedia.org/wiki/Stigler%27s_law_of_eponymy>

Yep--for some reason that worked.

------
tlb
Paper: <http://arxiv.org/pdf/1201.2501v1>

It starts by dividing the spectrum into frequency bins, and assumes that there
is usually 0 or 1 non-zero coefficients in each bin. It wasn't clear to me
what happens when a large number of non-zero coefficients are clustered
together in one bin. Can O(k log n) still be achieved when most frequencies
are clustered?

------
rasur
Interesting. I've a friend in Australia who's been doing some work analysing
rainfall using arrays of wire across long distances (details somewhere here:
<http://wiredlab.org/>), and during a recent conversation he pointed me at
this paper: <http://www.icita.org/icita2004/abstracts/128-5.htm> which seems
to use another method (involving Primes) for calculating Fourier Transforms,
and claims a 95% speed up.

Sadly I haven't had a chance to look into it in any great detail yet, although
it's "in the queue" of things to poke at. I thought it worth pointing out in
case anyone else might find it useful.

------
mjb
Spare transforms like this are very interesting, and these seem like some very
good performance results. It's worth noting, though, that FFTW
(<http://www.fftw.org/>) is still much faster on the sizes of transforms that
many (most?) applications do - less than 2^15 or so entries. Also, as the
number of non-zero frequencies climbs, sparse algorithms very quickly get
overtaken by good implementations of more standard FFT algorithms.

Still, very cool stuff.

~~~
mitmatt
They actually point out a specific comparison to FFTW in the paper: their
"preliminary implementation" is faster than FFTW for n=2^22 and k<=2^17, and
they point out that this performance is a distinct advantage over previous
algorithms, which were faster for only k<=2000 or so. In other words, it seems
that this algorithm is faster than FFTW for a much larger number of non-zero
frequencies than was previously possible.

I don't know how to estimate what values of n would be relevant for today's
applications, but n=2^22≈4M doesn't seem like such a big number for images or
video (if signal length roughly corresponds to number of pixels). Any
thoughts?

~~~
mjb
> I don't know how to estimate what values of n would be relevant for today's
> applications, but n=2^22≈4M doesn't seem like such a big number for images
> or video (if signal length roughly corresponds to number of pixels). Any
> thoughts?

Transform codecs for video typically don't transform an entire frame at a
time, but rather blocks of the frame. This is for three reasons. The first is
efficiency - most of these codecs date back to a time when huge transforms
(FFT, DCT, etc) were very expensive. Possibly the most important is the local
artifacts are less noticable than global artifacts in video, and using blocks
is a nice way to bound that. Finally, the point of using a transform is to be
able to extract some 'structure' from the data that can be used to encode it
in a more efficient way. Small blocks make this easier to do in a perceptually
acceptable or transparent way.

There are absolutely applications for large transforms, but video encoding
typically isn't one. Incidentally, many modern approaches are based on other
transforms, like the discrete wavelet transform, or approximations to
transforms like the DCT.

------
astrange
As usual the article misrepresents video compression. Almost l useful coding
tools are spatial and not frequency based; the only famous one (DCT) was
replaced with a rough approximation in H.264 and it works just as well.

This is because lots of realistic images don't really have meaningful
frequency-based content. (imagine sampling every 8 or 16 pixels - would their
values be in any way related to each other?)

~~~
Retric
Don't think of them in terms the full function. You can approximate a strait
line by a small part of a long sine wave.
[http://www.wolframalpha.com/input/?i=Sin%28x%29++from+.01+to...](http://www.wolframalpha.com/input/?i=Sin%28x%29++from+.01+to+.02)

But, for a real world example look at jpeg.

 _Next, each 8×8 block of each component (Y, Cb, Cr) is converted to a
frequency-domain representation, using a normalized, two-dimensional type-II
discrete cosine transform (DCT)._ <http://en.wikipedia.org/wiki/JPEG>

------
radarsat1
I guess this is the project page, also contains the papers and some
benchmarks:

<http://groups.csail.mit.edu/netmit/sFFT>

------
shabble
For the plain ol' FFT, I've found the "Fastest Fourier in the West":
<http://www.fftw.org/> to be an excellent library, which implements a whole
bunch of different solvers, and picks the appropriate ones to use for your
data.

Hopefully this new algorithm can be added to their toolbox in the future.

~~~
saulrh
In the paper, they state that they compared their implementation to FFTW and
beat it handily.

------
Geee
There's lots of things you can do with practical algorithms when you start
thinking data-first approaches and try to fit the optimizations to the
probability distribution of the data, i.e. fastest path for the most probable
or important input and vice versa. Many approximations are based on the idea
of ignoring input data which is improbable or has little effect on the
outcome, and can be quite safely pruned out early.

~~~
edge17
Or as they say in computer architecture 101, optimizing for the common case :)

------
cschmidt
Here's the SODA paper:

<http://nms.lcs.mit.edu/~dina/pub/soda12.pdf>

------
ot
The talk at SODA is in 1.5 hours, I'm going to attend it.

Any other HNers at SODA?

~~~
cschmidt
How was the talk?

------
brlewis
Is the algorithm patented?

~~~
pbhjpbhj
Mathematical methods ( _as such_!) are a specific exclusion in Europe (EPC
52(2) &(3)).

Of course that _as such_ gives you somewhere to hang your patent application
if you can afford the patent lawyers fees to protect the monopoly.

~~~
brlewis
Mathematical methods are excluded in the U.S. too by case law (Benson, Flook,
Diehr). But "law" in terms of what's on the books and "law" in terms of what
happens when you go to court are two different things.

------
kitsune_
This is very interesting, thank you. I'll try to implement it this weekend.

