Re: "Discrete Hartley transform" vs " Discrete Fouuier transform"

On Oct 18, 5:49=A0pm, "VelociChicken" <b...@[EMAIL PROTECTED]
> wrote:
> I take it that's the Mayer FHT not the FFT tested there. Anyway, can't
> refute that, and I'll look through them again at some point. It may well
> have been the combination with my convolution code or some trig settings
=
on
> the other FFT's. Kinda weird though...

The "rmayer" code in the graphs is the real-data FFT computed via the
FHT (Mayer's reallfft routine).  That involves one additional pass
over the array in Mayer's code compared to his FHT by itself, but the
difference is tiny.  If I benchmark his FHT by itself, it's slightly
faster (e.g. 3% faster for n=3D16384 and 7% faster for n=3D512 on my
current machine) due to omitting that one pass, but that's not nearly
enough to make up for the factor of 4 difference in speed compared to
the other codes in the benchmark.

There's nothing wrong with Ron Mayer's code; it's a perfectly
reasonable, decently optimized, clean implementation of a power-of-two
FHT, and is competitive with a number of available real-input FFT
routines; it's comparable to a radix-4 or radix-8 FFT.  It's certainly
better than your run-of-the-mill Numerical-Recipes radix-2 FFT code.
But it doesn't exhibit any clear advantage over similarly optimized
real-input FFTs, and can't compete with much more heavily optimized
implementations of the latter.

Steven