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