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
"Discrete Hartley transform" vs " Discrete Fouuier transform"
Started by ●October 9, 2008
Reply by ●October 10, 20082008-10-10
On Oct 9, 9:02 pm, Richard Owlett <rowl...@atlascomm.net> 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? > > TIARichard, 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.
Reply by ●October 10, 20082008-10-10
julius wrote:> On Oct 9, 9:02 pm, Richard Owlett <rowl...@atlascomm.net> 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.
Reply by ●October 10, 20082008-10-10
julius wrote:> On Oct 9, 9:02 pm, Richard Owlett <rowl...@atlascomm.net> 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.
Reply by ●October 10, 20082008-10-10
julius wrote:> On Oct 9, 9:02 pm, Richard Owlett <rowl...@atlascomm.net> 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.
Reply by ●October 10, 20082008-10-10
On Fri, 10 Oct 2008 11:54:52 -0500, Richard Owlett <rowlett@atlascomm.net> wrote:>julius wrote: >> On Oct 9, 9:02 pm, Richard Owlett <rowl...@atlascomm.net> 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. There's a book called "The Hartley Transform" by Bracewell that is a good reference if you can find it or need it. The output symmetries of the FHT can be non-obvious at first, but once you sort them out it is very easy to use and functionally equivalent to the FFT. Eric Jacobsen Minister of Algorithms Abineau Communications http://www.ericjacobsen.org Blog: http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.php
Reply by ●October 10, 20082008-10-10
Eric Jacobsen <eric.jacobsen@ieee.org> writes:> On Fri, 10 Oct 2008 11:54:52 -0500, Richard Owlett > <rowlett@atlascomm.net> wrote: > >>julius wrote: >>> On Oct 9, 9:02 pm, Richard Owlett <rowl...@atlascomm.net> 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. -- % Randy Yates % "The dreamer, the unwoken fool - %% Fuquay-Varina, NC % in dreams, no pain will kiss the brow..." %%% 919-577-9882 % %%%% <yates@ieee.org> % 'Eldorado Overture', *Eldorado*, ELO http://www.digitalsignallabs.com
Reply by ●October 10, 20082008-10-10
On Fri, 10 Oct 2008 13:37:42 -0400, Randy Yates <yates@ieee.org> wrote:>Eric Jacobsen <eric.jacobsen@ieee.org> writes: > >> On Fri, 10 Oct 2008 11:54:52 -0500, Richard Owlett >> <rowlett@atlascomm.net> wrote: >> >>>julius wrote: >>>> On Oct 9, 9:02 pm, Richard Owlett <rowl...@atlascomm.net> 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-port 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 circumstances. 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
Reply by ●October 10, 20082008-10-10
On Fri, 10 Oct 2008 13:37:42 -0400, Randy Yates <yates@ieee.org> wrote:>Eric Jacobsen <eric.jacobsen@ieee.org> writes: > >> On Fri, 10 Oct 2008 11:54:52 -0500, Richard Owlett >> <rowlett@atlascomm.net> wrote: >> >>>julius wrote: >>>> On Oct 9, 9:02 pm, Richard Owlett <rowl...@atlascomm.net> 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-port 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 circumstances. 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
Reply by ●October 10, 20082008-10-10
On Fri, 10 Oct 2008 13:37:42 -0400, Randy Yates <yates@ieee.org> wrote:>Eric Jacobsen <eric.jacobsen@ieee.org> writes: > >> On Fri, 10 Oct 2008 11:54:52 -0500, Richard Owlett >> <rowlett@atlascomm.net> wrote: >> >>>julius wrote: >>>> On Oct 9, 9:02 pm, Richard Owlett <rowl...@atlascomm.net> 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-port 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 circumstances. 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
