On Fri, 17 Oct 2008 16:18:20 -0700 (PDT), "Steven G. Johnson"
<stevenj@[EMAIL PROTECTED]
> wrote:
>On Oct 17, 2:41 pm, Eric Jacobsen <eric.jacob...@[EMAIL PROTECTED]
> wrote:
>> Dude, chill. I've no dog in this hunt, I'm merely pointing out that,
>> just like with most things, there are some subtleties where one may
>> have an advantage over the other given particular constraints. Is
>> that so surprising? They're not identical, you know.
>
>You initially claimed "some real advantages" for the FHT in terms of
>"computing or memory resources," including "substantially smaller"
>memory requirements. Whenever you were pressed for specifics about
>these "subtleties," however, your examples turned out to be false.
>False statements bother me, especially when you are repeating myths
>that were debunked 20 years ago.
Actually, the issue is that I understand that such comparisons are
extremely context specific. So unless someone has done the
comparisons for a specific context at hand, it's all pretty much just
handwaving. You keep citing studies, but unless a study compared the
issues in the context of the specific resource limitations in
computing and memory of interest in a particular application, it's
just academic.
I understand this. You seem to be arguing that because a bunch of
papers came to some conclusion that that conclusion must be true for
everyone, everywhere. I disagree with that standpoint, and I've
tried to explain why as well as I can. I don't know why you think
this it is so im****tant to promote FFTs as being better than or equal
to FHTs. I'm just saying there are tradeoffs, as is typically the
case with just about everything, anyway.
>> Unless you want to claim that an FFT always provides a superior
>> implementation op****tunity compared to an FHT under all possible
>> cir***stances I don't think there's an argument here.
>
>I made no such claim.
I know that. That's why I started the statement with "Unless you
want to claim that...". If you're not making that claim then I
really don't understand the cause for concern.
> I stated repeatedly that they are (as far as is
>currently known) almost identical with respect to memory usage
>(including access patterns), arithmetic, and organization/structure.
>Old claims that one has a substantial performance advantage over the
>other have been repeatedly disproved in the literature.
Repeatedly disproved in the literature for what context? Do you
understand that someone implementing a transform in an FPGA or a
silicon target is constrained by the memory architectures and
processing elements available in the libraries? Sometimes those
elements lend themselves well to a particular implementation and not
to others. Sometimes, especially when power and real estate are a
concern, minimizing certain elements can be particularly advantageous.
Do you claim that all of these studies that have "repeatedly disproved
in the literature" that the FHT can sometimes make sense considered
ALL of the various permutations of practical resource limitations?
That's some set of magical studies if that's the case.
>> There are times when an obscure tool or technique can provide an
>> advantage. Being aware of the obscure tools and the differences
>> allows that to be part of the tradeoff space.
>
>Repeating long-debunked myths about obscure tools does not help people
>to understand them better.
Repeatedly citing "the literature" as the final authority for every
case, everywhere is a poor substitute for actually being able to
*****s tradeoffs for oneself.
>The DHT certainly has some interesting properties, and is a nice
>transform to think about from time to time. (For example, in one of
>our own papers we showed that DHTs give a simple way to apply Rader's
>algorithm for prime-length transforms to purely real data, although
>Burrus in 1982 showed that there is a way to do this directly for real-
>data FFTs too.) But early claims of significant performance or memory
>advantages from FHT algorithms for power-of-two sizes have, sadly, not
>withstood the test of time.
>
>Regards,
>Steven G. Johnson
I recall some of the claims in the early 80s of the vast superiority
of the FHT for real-valued input transforms. It was clear to me from
the first time I looked into it (around that time) that the
differences would not be huge and would be application and
implementation dependent. That's the story I've been telling here,
and I really don't understand why you think that's a problematic
position (and I think it's still accurate).
Given that the two transforms are different, it would seem pretty
logical that the differences would lead to advantages one way or other
depending on different cir***stances.
Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org
Blog: http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.php
|
