Path: utzoo!attcan!uunet!husc6!purdue!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.misc
Subject: Re: fft routine (was Re: m88000 benchmarks)
Message-ID: <12307@mimsy.UUCP>
Date: 4 Jul 88 19:44:26 GMT
References: <1359@claude.oakhill.UUCP> <12295@mimsy.UUCP> <16920@sgi.SGI.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 86

>In article <12295@mimsy.UUCP> I griped about an fft routine:
>>... there are no comments; the variables
>>have names that tell nothing.  In short, the code is unmaintainable.

(which was not entirely true, but there were variables `ia', `n1', `n2',
`m', `n' which had various conditions asserted that were never mentioned.
For instance, m had to be log2(n); this was up to the caller to get right.
There is nothing inherently wrong with that, but it should certainly
be noted in the code!)

In article <16920@sgi.SGI.COM> karsh@trifolium.SGI.COM (Bruce Karsh) writes:
>  There is an extensive literature on the fft algorithm.

True enough, and one could be expected to read some of it before working
with that routine, but:

>  Why should somebody who has not read about how fft's work be expected to
>be able to "maintain" one?

This sort of thing always happens, even though it should not.  It helps
to put a pointer to some reference in a comment.

>  ... I would point out:
>     That n is a function of m.  In fact, n = 1<     passed in, it should be computed.  (Does anyone know of a good reason
>     why anybody would ever want to run this with n != 1<     That C compilers will perform the "float" arithmetic as "double"
>     ....  Many compilers have an option switch to allow
>     float ... should compile ... with that switch turned on.

Actually, I did, when I was checking the code generated by the various
versions.  But since that option is not standard it is hard to turn it
on from code.  (4.3BSD uses `cc -f'; SunOS uses `cc -fsingle'.)

>>		/*
>>		 * as k goes from to 0 n-1,
>>		 * fullstep goes from n to n/2 to n/4 to ... to 2,
>>		 * and halfstep goes from n/2 to n/4 to ... to 1.
>>		 */

Ack!

>     This comment has at least two errors in it.  First, k goes from
>     0 to m-1, not n-1.  Secondly, halfstep starts at n/4, not n/2.

Sloppy editing on my part (including the `from to 0' phrasing).

>     Secondly, both comments are gratuitous in that they give no more
>     information than what is immediately visible in the source code.

(Two `secondly's?)  The point is that this is not *immediately*
visible, especially in the original version, where `fullstep' and
`halfstep' were n1 and n2.  (The comments went in before I changed the
code to shift by k.)

>     It's kind of like saying:
>
>        pi=7.3232;    /* set pi to 7.3232 */

Actually, it is a bit more like

	pi = 7.3232;	/* 2.3311 * 3.1415 */

:-)

>     The comment tells you something that you already know, but doesn't
>     answer the question that you have!  What you don't know, and what
>     you want the comment to tell you, is why are you changing the value
>     of pi, and where did 7.3232 come from anyways?

Well, once you know that w[t] *really* stands for omega sub theta (sine
and cosine of the angle), and the complex arithmetic is visible, then
the mathematical means by which an FFT transforms becomes immediately
obvious from the source :-) ....

More seriously, the whole system should probably be redone.  As Richard
Harter pointed out, a complete FFT package should have code to set up
w[], calcuate m=log2(n), and all that sort of stuff.  But all I wanted
to do was make the inner loop obvious without losing efficiency.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris