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

On Oct 10, 3:42=A0pm, Eric Jacobsen <eric.jacob...@[EMAIL PROTECTED]
> wrote:
> I think it depends on the details of the resource issues. =A0 The FHT is
> nice from a memory perspective if the input is real-valued since you
> don't have to do any buffer manipulation, whereas with an N/2-pt FFT
> you may need to fiddle with the appropriate buffering/addressing to
> arrange the input properly. =A0 Similar issue with the output.

Nope, there is no intrinsic implementation advantage of an FHT that
I'm aware of; we looked carefully at this issue when working on FFTW.
(Sorensen in 1987 showed that there are real-valued FFT algorithms
that have a very similar structure to FHT algorithms.  Of course, all
of this is a bit moot because highly optimized FFT codes these days
look a lot different from the 1960s-1980s radix-2 and split-radix
algorithms.)

> In my experience the real advantage of the FHT was the memory
> requirement, which can be substantially smaller than an FFT depending
> on the constraints and what you're doing. =A0

Not true.  FHTs and real-input FFTs have essentially the same memory
requirements (obviously depending upon the implementation, but there
is no intrinsic advantage one way or the other).

> Another potential memory saving is in the twidlle factors, since the
> FHT has a single reference function [cas()], instead of sin() and
> cos().

Nope, there's no savings here either, because if you count carefully
you'll discover that you need half as many (sin,cos) pairs as cas
functions, so the number of constants balances out.

Steven