On Fri, 10 Oct 2008 13:37:42 -0400, Randy Yates <yates@[EMAIL PROTECTED]
>
wrote:
>Eric Jacobsen <eric.jacobsen@[EMAIL PROTECTED]
> writes:
>
>> On Fri, 10 Oct 2008 11:54:52 -0500, Richard Owlett
>> <rowlett@[EMAIL PROTECTED]
> wrote:
>>
>>>julius wrote:
>>>> On Oct 9, 9:02 pm, Richard Owlett <rowl...@[EMAIL PROTECTED]
> wrote:
>>>>
>>>>>I'm interested in Magnitude vs Frequency.
>>>>>I have a strictly Real input sequence.
>>>>>There's Fast Hartley transform code available for my preferred
language.
>>>>>Relative speed is not an issue as I'm working on stored data.
>>>>>
>>>>>What gotcha's should I watch out for?
>>>>>Is the a good comparison on the web of their practical differences?
>>>>>
>>>>>TIA
>>>>
>>>>
>>>> Richard, maybe it's better if you tell us what your intended
>>>> application
>>>> is. Right now it sounds a bit like asking whether you should buy a
>>>> sedan
>>>> or a hatchback :-P. There will be lots of opinions, but they are
>>>> worthless
>>>> depending on your situation and application.
>>>
>>>Well, my app is about as simple as it gets.
>>>I have a time sequence f(t) and I want a measure of abs(f(omega))
>>>Signal so far has been audio, but don't think that bears on question.
>>>I'm not going to filter/process/... the transformed data, just plot it.
>>>I have been using an FFT so far.
>>>I wish to change hardware/OS/etc.
>>>There is existing FHT code that I can cut and paste.
>>>Wikipedia article seemed to imply FHT lost favor to FFT when faster FFT
>>>algorithms were developed.
>>
>> Back when processing power and memory were hard to come by I used to
>> use FHTs a lot. As you mention, they're very good when the input is
>> real-valued, and if you only need the magnitude output for a plot
>> it'll be pretty efficient.
>>
>> Since processing power and memory are cheap these days everybody just
>> plugs in FFTs. When computing or memory resources are hard to come
>> by, though, the FHT can have some real advantages.
>
>I thought that, when using the trick of an N-point FFT to get the
>transform of 2 N-point real sequences, the FHT has no computational
>advantage whatsoever over the FFT? But to answer Richard's question,
>there's nothing wrong or disadvantageous in using it.
I think it depends on the details of the resource issues. 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. Similar issue with the output.
The output of the FHT can be problematic if you don't optimise for it,
but, again, if you just want a magnitude spectrum or something it's
pretty easy to pull it out of the native output vector, especially if
a dual-****t is used for the output buffer.
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. Since memory is seldom a
constraint these days it's pretty moot.
Another potential memory saving is in the twidlle factors, since the
FHT has a single reference function [cas()], instead of sin() and
cos(). Clearly it just depends on how you're trying to get it
implemented. These sorts of things only come into play if your'e
really tight on certain resources, but it can make a big difference in
the right cir***stances.
I'm not surprised that the FHT (and other things like it) are largely
unknown since canned FFTs and the like are pretty easy to plug in.
Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org
Blog: http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.php
|
