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

On Oct 16, 4:19=A0pm, Eric Jacobsen <eric.jacob...@[EMAIL PROTECTED]
> wrote:
> Again, it's a bit more complicated than just counting how much memory
> is needed. =A0 How it's used can make a big difference, too. =A0
=A0Since
> the FHT can directly take the real-valued input buffer in the time
> order in which it is presented, there can be an advantage depending
> (again) on the implementation and what you're trying to do. =A0 The same
> is true on the output, the same is true in the way that the twiddle
> tables are used.

If you are implying that the FHT operates on in-order input and
output, while a real-data FFT cannot, then you're wrong.

> Things like incrementing a pointer into a memory is easier (and
> typically faster) than manipulating an address via a computation. That
> can make a significant difference and isn't reflected by just
> analyzing memory sizes.

Of course, but there's no significant difference between FHTs and real-
data FFTs in this regard.  (This has been pointed out again and again
in the literature on the subject, dating back to the late 1980s.)

However, since you feel so strongly to the contrary, I look forward to
your pointing out an FHT implementation that beats the best known real-
data FFT implementation by a significant margin for any modern CPU.
I'm sure that such an FHT implementation will see widespread use once
its performance has been demonstrated, and for my own part I try to
keep abreast of the latest developments in the field.

> And optimizing transforms for computation on a CPU is only relevant to
> comparisons on that CPU. =A0 I'm looking at it far more generically, as
> the sorts of applications where the difference may matter may not be
> run on a CPU or DSP at all.

If you're going to distance yourself from readily available computers
where your claims can be tested, there's not much to talk about.

Steven