WEBVTT
00:00:00.090 --> 00:00:02.490
The following content is
provided under a Creative
00:00:02.490 --> 00:00:04.030
Commons license.
00:00:04.030 --> 00:00:06.330
Your support will help
MIT OpenCourseWare
00:00:06.330 --> 00:00:10.720
continue to offer high quality
educational resources for free.
00:00:10.720 --> 00:00:13.320
To make a donation or
view additional materials
00:00:13.320 --> 00:00:17.280
from hundreds of MIT courses,
visit MIT OpenCourseWare
00:00:17.280 --> 00:00:18.430
at ocw.mit.edu.
00:00:22.330 --> 00:00:48.345
[MUSIC PLAYING]
00:00:48.345 --> 00:00:50.340
PROFESSOR: In the
last lecture, we
00:00:50.340 --> 00:00:53.820
introduced an alternative
set of algorithms
00:00:53.820 --> 00:00:57.690
for computation of the
fast Fourier transform
00:00:57.690 --> 00:01:00.930
or rather, computation of the
discrete Fourier transform.
00:01:00.930 --> 00:01:05.040
And we refer to these as
the decimation in frequency
00:01:05.040 --> 00:01:06.990
form of the algorithm.
00:01:06.990 --> 00:01:10.900
As you recall, we
developed the decimation
00:01:10.900 --> 00:01:13.380
in frequency form
of the algorithm
00:01:13.380 --> 00:01:17.730
by essentially organizing
the computation of the even
00:01:17.730 --> 00:01:24.390
numbered DFT points and the odd
numbered DFT points separately
00:01:24.390 --> 00:01:27.820
and then proceeded
in a similar manner.
00:01:27.820 --> 00:01:31.290
This corresponded to breaking
the computation into two
00:01:31.290 --> 00:01:35.400
and over two point DFT's
proceeded in a similar manner
00:01:35.400 --> 00:01:38.910
to decompose the computation
of these separately
00:01:38.910 --> 00:01:41.937
into their even numbered points
and odd numbered points, et
00:01:41.937 --> 00:01:42.660
cetera.
00:01:42.660 --> 00:01:48.690
And the flow graph that resulted
from this procedure was--
00:01:48.690 --> 00:01:51.460
as I've shown here--
00:01:51.460 --> 00:01:55.540
which is one form,
then, of the decimation
00:01:55.540 --> 00:02:01.890
in frequency form of the fast
Fourier transform algorithm.
00:02:01.890 --> 00:02:08.699
It begins with the data sorted
in normal order and proceeds
00:02:08.699 --> 00:02:12.090
to the data sorted in
big reversed order.
00:02:12.090 --> 00:02:14.940
And as I stressed
last time, it also
00:02:14.940 --> 00:02:19.560
corresponds to an in-place
computation because of the way
00:02:19.560 --> 00:02:22.410
in which the butterflies
are laid out.
00:02:22.410 --> 00:02:26.190
In particular, the output
nodes for each butterfly
00:02:26.190 --> 00:02:30.300
are horizontally adjacent
to the input nodes.
00:02:30.300 --> 00:02:35.160
Now this is similar in
a number of respects
00:02:35.160 --> 00:02:41.070
to one of the decimation in
time forms of the FFT algorithm.
00:02:41.070 --> 00:02:44.440
Although, as I also
indicated last time,
00:02:44.440 --> 00:02:47.280
the basic structure of
the butterfly computation
00:02:47.280 --> 00:02:48.570
is somewhat different.
00:02:48.570 --> 00:02:53.510
In particular, for
this set of algorithms,
00:02:53.510 --> 00:02:56.520
the multiplication
by powers of W
00:02:56.520 --> 00:02:59.850
is implemented at the
output of the butterfly,
00:02:59.850 --> 00:03:02.970
as opposed to the
decimation in time forms,
00:03:02.970 --> 00:03:05.430
where the multiplication
by powers of W
00:03:05.430 --> 00:03:09.300
are implemented at the
input to the butterfly.
00:03:09.300 --> 00:03:12.900
However, there is a
very close relationship
00:03:12.900 --> 00:03:17.850
between this flow graph
and the original flow graph
00:03:17.850 --> 00:03:23.160
that we implemented for the
decimation in time algorithm.
00:03:23.160 --> 00:03:25.620
In particular, the
two flow graphs
00:03:25.620 --> 00:03:28.630
are transposes of each other.
00:03:28.630 --> 00:03:32.280
Now I remind you that in
one of the early lectures,
00:03:32.280 --> 00:03:36.360
when we introduced the notation
of flow graphs and some
00:03:36.360 --> 00:03:39.090
of the properties
of flow graphs,
00:03:39.090 --> 00:03:42.780
one of the properties of flow
graphs that I mentioned--
00:03:42.780 --> 00:03:44.400
although we didn't derive it--
00:03:44.400 --> 00:03:48.120
was the fact that
transposition of a flow graph
00:03:48.120 --> 00:03:51.670
doesn't change the input
output characteristics.
00:03:51.670 --> 00:03:56.550
So then in fact, if we took
this flow graph, changed
00:03:56.550 --> 00:03:59.550
the direction of
all of the arrows,
00:03:59.550 --> 00:04:02.640
treated this set of
nodes as the input nodes
00:04:02.640 --> 00:04:05.820
and this set of nodes
as the output nodes,
00:04:05.820 --> 00:04:09.660
then since the flow graph,
as it's indicated here,
00:04:09.660 --> 00:04:12.510
computes the discrete
Fourier transform,
00:04:12.510 --> 00:04:15.120
the transposed flow
graph would also
00:04:15.120 --> 00:04:17.709
compute the discrete
Fourier transform.
00:04:17.709 --> 00:04:21.269
And in fact, the transposition
of this flow graph
00:04:21.269 --> 00:04:25.820
is identical to the
first flow graph--
00:04:25.820 --> 00:04:28.260
FFT flow graph--
that we introduced,
00:04:28.260 --> 00:04:32.070
which was the initial
decimation in time form.
00:04:32.070 --> 00:04:37.410
And that I refer
you to again, here.
00:04:37.410 --> 00:04:41.670
So this is the
decimation in time form
00:04:41.670 --> 00:04:44.490
of the algorithm with
the input bit reversed
00:04:44.490 --> 00:04:47.220
and the output in normal order.
00:04:47.220 --> 00:04:55.710
This is the transposition
of this flow graph, which
00:04:55.710 --> 00:04:59.340
is the decimation in frequency
form of the algorithm
00:04:59.340 --> 00:05:02.880
with the input in normal
order and the output in bit
00:05:02.880 --> 00:05:04.830
reversed order.
00:05:04.830 --> 00:05:08.430
The fact that these are
related through transposition
00:05:08.430 --> 00:05:12.420
of the flow graph isn't a
particularly important point
00:05:12.420 --> 00:05:14.310
from a practical point of view.
00:05:14.310 --> 00:05:17.700
But it is a useful
piece of insight
00:05:17.700 --> 00:05:22.321
into the relationship between
these various algorithms.
00:05:22.321 --> 00:05:25.860
All right, now just as we
did with the decimation
00:05:25.860 --> 00:05:29.580
in time forms of
the algorithm, we
00:05:29.580 --> 00:05:34.590
can rearrange the decimation in
frequency form of the algorithm
00:05:34.590 --> 00:05:41.790
to either arrange the output to
be in normal order, as opposed
00:05:41.790 --> 00:05:44.040
to having the input
in normal order,
00:05:44.040 --> 00:05:47.010
or rearrange it so that both
the input and output are
00:05:47.010 --> 00:05:50.910
in normal order or
rearrange it as we will,
00:05:50.910 --> 00:05:54.090
so that we can utilize
sequential memory rather
00:05:54.090 --> 00:05:56.880
than random access memory.
00:05:56.880 --> 00:06:00.210
To rearrange the flow
graph so that the output is
00:06:00.210 --> 00:06:03.330
in normal order, we
would, again, simply
00:06:03.330 --> 00:06:07.920
take horizontal lines
and re-sort them
00:06:07.920 --> 00:06:13.680
so that the output nodes are
sorted in a normal order.
00:06:13.680 --> 00:06:18.150
And the flow graph
that results is
00:06:18.150 --> 00:06:24.120
a decimation in frequency
form of the algorithm,
00:06:24.120 --> 00:06:30.030
for which the outputs
are in normal order.
00:06:30.030 --> 00:06:35.520
But the inputs are in
bit reversed order.
00:06:35.520 --> 00:06:38.880
Again, as this flow
graph has been sorted,
00:06:38.880 --> 00:06:42.180
it is an in-place computation.
00:06:42.180 --> 00:06:45.450
In-place, again, because
the butterflies are laid out
00:06:45.450 --> 00:06:50.280
in such a way that they involve
horizontally adjacent nodes.
00:06:50.280 --> 00:06:52.950
So this is an
in-place computation
00:06:52.950 --> 00:06:55.860
with the input in
bit reversed order
00:06:55.860 --> 00:06:59.730
and the output in normal order.
00:06:59.730 --> 00:07:10.170
Again this is a transposition
of one of the flow graphs
00:07:10.170 --> 00:07:12.480
that we discussed in
the previous lecture.
00:07:12.480 --> 00:07:16.860
In particular, it is a
transposition of the flow graph
00:07:16.860 --> 00:07:20.880
for which, if you imagine this
flow graph being transposed
00:07:20.880 --> 00:07:23.430
so that the direction of
the arrows are reversed
00:07:23.430 --> 00:07:26.400
and this is the input,
then it corresponds
00:07:26.400 --> 00:07:29.880
to the decimation in time form
of the algorithm for which
00:07:29.880 --> 00:07:34.410
the input is in normal order
and the output comes out
00:07:34.410 --> 00:07:36.280
in bit reversed order.
00:07:36.280 --> 00:07:42.720
And that is the flow graph
that I have indicated here.
00:07:42.720 --> 00:07:47.550
So this is a decimation in time
form of the algorithm, which
00:07:47.550 --> 00:07:52.710
is the transposition of
the decimation in frequency
00:07:52.710 --> 00:07:58.230
form of the algorithm
that we just looked at.
00:07:58.230 --> 00:08:05.320
All right, that corresponds
then to two possible decimation
00:08:05.320 --> 00:08:07.560
in frequency algorithms.
00:08:07.560 --> 00:08:10.060
One in which the input
is in normal order,
00:08:10.060 --> 00:08:11.850
the output is bit reversed.
00:08:11.850 --> 00:08:14.970
This one in which the input
is bit reversed and the output
00:08:14.970 --> 00:08:17.190
is in normal order.
00:08:17.190 --> 00:08:21.000
We can also rearrange
this so that the input is
00:08:21.000 --> 00:08:24.300
in normal order and the
output is in normal order.
00:08:24.300 --> 00:08:28.110
And the flow graph that
results when we implement that
00:08:28.110 --> 00:08:35.500
is similar to the corresponding
decimation in time flow graph.
00:08:35.500 --> 00:08:40.530
In fact, it is a transposition
of that flow graph.
00:08:40.530 --> 00:08:45.300
And just as we found in the
decimation in time algorithm,
00:08:45.300 --> 00:08:49.440
for this case, although the
input is sorted in normal order
00:08:49.440 --> 00:08:52.390
and the output comes
out in normal order,
00:08:52.390 --> 00:08:56.190
the indexing is
generally complicated
00:08:56.190 --> 00:08:58.920
as we proceed from
stage to stage.
00:08:58.920 --> 00:09:01.980
And furthermore, it
does not correspond
00:09:01.980 --> 00:09:05.820
to an in-place computation,
because of the fact
00:09:05.820 --> 00:09:09.990
that the outputs
of the butterflies
00:09:09.990 --> 00:09:14.040
are no longer horizontally
adjacent to the inputs
00:09:14.040 --> 00:09:15.810
to the butterfly.
00:09:15.810 --> 00:09:19.050
So generally, this flow
graph and its decimation
00:09:19.050 --> 00:09:26.500
in time counterpart are not
practically very important.
00:09:26.500 --> 00:09:30.180
A final rearrangement
of the flow graph
00:09:30.180 --> 00:09:36.390
is the rearrangement
which permits
00:09:36.390 --> 00:09:41.490
the use of sequential memory
rather than random access
00:09:41.490 --> 00:09:42.570
memory.
00:09:42.570 --> 00:09:46.350
And this, then,
is the flow graph
00:09:46.350 --> 00:09:49.020
that is the counterpart
to the flow graph
00:09:49.020 --> 00:09:51.390
that we discussed last
time, which I referred to
00:09:51.390 --> 00:09:56.460
as the Singleton algorithm,
or I attributed to Singleton.
00:09:56.460 --> 00:10:02.210
This is a variation of
that type of algorithm,
00:10:02.210 --> 00:10:07.350
in which now, again, we
recognize that the indexing is
00:10:07.350 --> 00:10:12.120
identical from stage to stage.
00:10:12.120 --> 00:10:14.370
The input is in normal order.
00:10:14.370 --> 00:10:17.950
And the output comes out
in bit reversed order.
00:10:17.950 --> 00:10:21.270
And let me just
compare this for you
00:10:21.270 --> 00:10:23.700
with the corresponding
flow graph
00:10:23.700 --> 00:10:29.370
that we had last time,
which I've indicated here.
00:10:29.370 --> 00:10:32.040
That has the input
in bit reversed
00:10:32.040 --> 00:10:34.200
order, the output
in normal order.
00:10:34.200 --> 00:10:37.440
In fact, the transposition
of this flow graph
00:10:37.440 --> 00:10:40.410
is the decimation
in frequency form
00:10:40.410 --> 00:10:44.400
of the algorithm, for which
the input is in normal order,
00:10:44.400 --> 00:10:47.790
and the output is in
bit reversed order.
00:10:47.790 --> 00:10:52.020
All right, so the indexing is
identical from stage to stage.
00:10:52.020 --> 00:10:55.200
And just as we
had previously, we
00:10:55.200 --> 00:10:59.010
can implement this
algorithm by utilizing
00:10:59.010 --> 00:11:02.610
sequential memory as opposed
to random access memory.
00:11:02.610 --> 00:11:06.570
Although the organization of
the memory for the decimation
00:11:06.570 --> 00:11:10.020
in frequency form of
the Singleton algorithm
00:11:10.020 --> 00:11:13.230
is somewhat different
than the organization
00:11:13.230 --> 00:11:16.800
of the memory for the decimation
in time form of the Singleton
00:11:16.800 --> 00:11:18.420
algorithm.
00:11:18.420 --> 00:11:22.170
In particular, last time when
we discussed the decimation
00:11:22.170 --> 00:11:28.680
in time algorithm, we had four
memories, as we will this time.
00:11:28.680 --> 00:11:30.700
The first half of
the data in memory A,
00:11:30.700 --> 00:11:32.740
the second half of
the memory in memory
00:11:32.740 --> 00:11:37.170
B. We went, first of all,
through all of memory A,
00:11:37.170 --> 00:11:41.640
then through all of memory B,
storing results alternatively
00:11:41.640 --> 00:11:44.430
in memories C and D.
00:11:44.430 --> 00:11:48.180
In this case, the strategy
in utilizing the memory
00:11:48.180 --> 00:11:50.440
is somewhat different.
00:11:50.440 --> 00:11:57.910
In this case, we store the first
half of the data points, again,
00:11:57.910 --> 00:12:00.790
in memory A, the
second half of the data
00:12:00.790 --> 00:12:04.810
points, again, in memory
B. But notice that now
00:12:04.810 --> 00:12:11.470
in the computation utilizing
the computation for this point,
00:12:11.470 --> 00:12:16.930
for example, we use the first
output point from memory A
00:12:16.930 --> 00:12:20.140
and the first output
point from memory b.
00:12:20.140 --> 00:12:26.230
We store the result in the
first register in memory C
00:12:26.230 --> 00:12:30.100
and in the second
register in memory C.
00:12:30.100 --> 00:12:32.710
Then, to compute
the next two points,
00:12:32.710 --> 00:12:36.386
we take the next
point from memory A
00:12:36.386 --> 00:12:42.550
and the next point
from memory B,
00:12:42.550 --> 00:12:45.340
do the appropriate addition
and subtraction, multiplication
00:12:45.340 --> 00:12:52.360
by powers of W, and store
those in the next two registers
00:12:52.360 --> 00:12:55.420
in memory C. For this
particular example,
00:12:55.420 --> 00:12:58.300
namely n equals eight,
that fills up memory C.
00:12:58.300 --> 00:13:02.500
And we proceed, likewise,
accessing the input data,
00:13:02.500 --> 00:13:05.650
alternating between
the two input memories
00:13:05.650 --> 00:13:10.570
and storing data first in all
of one of the output memories
00:13:10.570 --> 00:13:14.230
and then in all of the second
of the output memories.
00:13:14.230 --> 00:13:18.670
And then we proceed in that
fashion from stage to stage.
00:13:18.670 --> 00:13:21.040
But again, one of
the important aspects
00:13:21.040 --> 00:13:23.770
is that it utilizes
sequential memory,
00:13:23.770 --> 00:13:28.180
for example, disk or drum or
tape or shift register memory.
00:13:32.340 --> 00:13:42.090
OK, so this then is
essentially a picture
00:13:42.090 --> 00:13:45.510
of a variety of the
algorithms, which
00:13:45.510 --> 00:13:49.620
can be used for the computation
of the discrete Fourier
00:13:49.620 --> 00:13:53.430
transform, some of
which were derived
00:13:53.430 --> 00:13:56.250
on the basis of a
decimation in time argument.
00:13:56.250 --> 00:14:00.720
Some were derived on the basis
of a decimation in frequency
00:14:00.720 --> 00:14:01.740
argument.
00:14:01.740 --> 00:14:05.310
But we saw, in fact, that the
decimation in frequency forms
00:14:05.310 --> 00:14:08.580
of the algorithm are,
in terms of flow graph
00:14:08.580 --> 00:14:11.610
notation or
interpretation, transposes
00:14:11.610 --> 00:14:15.750
of the decimation in time form.
00:14:15.750 --> 00:14:20.340
What I would like
to discuss now are
00:14:20.340 --> 00:14:23.820
a few of the
computational issues that
00:14:23.820 --> 00:14:28.980
are involved in the implementing
the fast Fourier transform
00:14:28.980 --> 00:14:35.850
algorithm and return, also, to
a brief discussion of at least
00:14:35.850 --> 00:14:39.120
one situation in which
there is a preference
00:14:39.120 --> 00:14:45.660
for using decimation in time or
using decimation in frequency.
00:14:45.660 --> 00:14:47.910
After we've discussed
some of the computational
00:14:47.910 --> 00:14:53.520
considerations, I will then
just very briefly discuss
00:14:53.520 --> 00:14:58.310
the generalization of the fast
Fourier transform algorithm
00:14:58.310 --> 00:15:01.350
to situations in which
the number of data points
00:15:01.350 --> 00:15:04.530
is not a power of
two, but is a more
00:15:04.530 --> 00:15:07.260
arbitrary composite number.
00:15:07.260 --> 00:15:11.220
Well first of all,
then, let me introduce
00:15:11.220 --> 00:15:14.280
a few of the
computational issues
00:15:14.280 --> 00:15:18.280
that I would like to
draw your attention to.
00:15:18.280 --> 00:15:24.450
The first is-- and it's a point
that I raised in the first
00:15:24.450 --> 00:15:27.630
lecture, in which I introduced
the fast Fourier transform
00:15:27.630 --> 00:15:28.920
algorithm--
00:15:28.920 --> 00:15:32.730
that whereas our discussion
has been directed entirely
00:15:32.730 --> 00:15:36.930
toward the computation
of the DFT,
00:15:36.930 --> 00:15:40.470
it applies also, in a
very straightforward way,
00:15:40.470 --> 00:15:45.120
to a computation
of the inverse DFT.
00:15:45.120 --> 00:15:49.110
In particular, we know that
the inverse discrete Fourier
00:15:49.110 --> 00:15:54.750
transform relationship is given
by 1 over N times the sum of x
00:15:54.750 --> 00:15:58.200
of k W sub-N to the minus NK.
00:15:58.200 --> 00:16:02.130
In contrast to the discrete
Fourier transform--
00:16:02.130 --> 00:16:04.240
that is the forward transform--
00:16:04.240 --> 00:16:07.200
which does not have
the factor of 1 over N
00:16:07.200 --> 00:16:14.080
and involves multiplication by
W sub-N to the plus NK, rather
00:16:14.080 --> 00:16:18.630
than W sub-N to the minus NK.
00:16:18.630 --> 00:16:23.280
To use the algorithms
that we have just
00:16:23.280 --> 00:16:27.090
been discussing
for the computation
00:16:27.090 --> 00:16:30.690
of the inverse discrete
Fourier transform,
00:16:30.690 --> 00:16:34.150
the modification is
relatively straightforward.
00:16:34.150 --> 00:16:36.180
First of all, it
involves a factor of 1
00:16:36.180 --> 00:16:40.420
over N, which we can
accommodate in a number of ways.
00:16:40.420 --> 00:16:43.920
One is, of course, by
shifting the output
00:16:43.920 --> 00:16:50.190
or by applying scaling at each
stage of the FFT, for example.
00:16:50.190 --> 00:16:54.930
So this factor of 1 over
N is easily accommodated.
00:16:54.930 --> 00:17:01.140
And the other difference
is the inclusion
00:17:01.140 --> 00:17:05.550
of a minus sign in the
exponent in powers of W
00:17:05.550 --> 00:17:09.060
rather than a plus sign
for the forward transform.
00:17:09.060 --> 00:17:14.099
That means, in essence,
that these coefficients
00:17:14.099 --> 00:17:18.450
are the complex conjugate
of these coefficients.
00:17:18.450 --> 00:17:27.720
Because W sub-capital N is e
of the J two pi over capital N.
00:17:27.720 --> 00:17:32.340
This minus sign represents
a conjugation of W.
00:17:32.340 --> 00:17:36.870
And so one procedure that we
can follow for implementing
00:17:36.870 --> 00:17:41.100
the inverse discrete Fourier
transform using all of the flow
00:17:41.100 --> 00:17:46.650
graphs that we've talked
about is simply conjugate
00:17:46.650 --> 00:17:51.960
the powers of W that are
involved in the computation.
00:17:51.960 --> 00:17:55.860
An alternative procedure,
which is basically equivalent,
00:17:55.860 --> 00:18:02.070
is to use the flow graphs
as they stand, in which case
00:18:02.070 --> 00:18:06.120
the output data,
which is obtained,
00:18:06.120 --> 00:18:13.110
is the desired result with
little n replaced by minus n.
00:18:13.110 --> 00:18:17.910
So we can either
compute the inverse DFT
00:18:17.910 --> 00:18:22.650
from an algorithm, which is
aimed at the forward DFT,
00:18:22.650 --> 00:18:26.130
by conjugating the
coefficients or equivalently
00:18:26.130 --> 00:18:33.360
by essentially flipping the
output, modulo capital N. So
00:18:33.360 --> 00:18:37.140
all of the algorithms that
we have talked about, then,
00:18:37.140 --> 00:18:39.390
relate in a very
straightforward manner
00:18:39.390 --> 00:18:42.360
to the computation of the
inverse discrete Fourier
00:18:42.360 --> 00:18:44.940
transform.
00:18:44.940 --> 00:18:47.040
The second issue
is that as we've
00:18:47.040 --> 00:18:50.640
seen in essentially
all of the algorithms
00:18:50.640 --> 00:18:56.500
of practical interest, they
involve either bit reversal
00:18:56.500 --> 00:19:01.300
at the input to the flow graph
or a bit reversal at the output
00:19:01.300 --> 00:19:03.496
of the flow graph.
00:19:03.496 --> 00:19:09.490
Bit reversal, again, is a
relatively straightforward
00:19:09.490 --> 00:19:12.120
thing to implement.
00:19:12.120 --> 00:19:17.880
First of all, it is important to
recognize that bit reversal is
00:19:17.880 --> 00:19:22.590
an in-place computation, if we
think of it as a computation.
00:19:22.590 --> 00:19:29.760
In particular, suppose that we
had the seven data indices zero
00:19:29.760 --> 00:19:31.690
through seven.
00:19:31.690 --> 00:19:36.990
And we want to rearrange
this data so that the data is
00:19:36.990 --> 00:19:40.200
arranged in bit reversed order.
00:19:40.200 --> 00:19:45.990
Well that means that, of course,
zero bit reversed is zero,
00:19:45.990 --> 00:19:48.300
one bit reversed is four.
00:19:48.300 --> 00:19:52.210
But of course, four
bit reversed is one.
00:19:52.210 --> 00:19:57.480
So in fact, we would
want to store data
00:19:57.480 --> 00:20:04.350
with whose index is one
in storage location four.
00:20:04.350 --> 00:20:07.920
But we will also want to
store data whose data index
00:20:07.920 --> 00:20:11.700
is four in storage location one.
00:20:11.700 --> 00:20:15.240
So in fact, implementing
the bit reversal
00:20:15.240 --> 00:20:21.210
can be accomplished in place
by essentially swapping
00:20:21.210 --> 00:20:23.260
these two pieces of data.
00:20:23.260 --> 00:20:26.440
Similarly of course,
two bit reverses two.
00:20:26.440 --> 00:20:28.080
And so that wouldn't move.
00:20:28.080 --> 00:20:30.310
Three bit reversed is six.
00:20:30.310 --> 00:20:32.760
But six bit reversed is three.
00:20:32.760 --> 00:20:36.660
And so again, we can
carry out that interchange
00:20:36.660 --> 00:20:38.700
as an in-place computation.
00:20:38.700 --> 00:20:43.140
So bit reversal, then, can
be implemented in place.
00:20:43.140 --> 00:20:47.760
And consequently, as
we restore the data
00:20:47.760 --> 00:20:50.670
in a bit reversed
order, we don't
00:20:50.670 --> 00:20:55.050
require double the storage,
since we can carry that out
00:20:55.050 --> 00:20:58.080
as an in-place operation.
00:20:58.080 --> 00:21:02.100
Second of all, to implement
bit reversal, of course,
00:21:02.100 --> 00:21:06.240
to implement bit reversal
in hardware, to obtain a bit
00:21:06.240 --> 00:21:08.910
reversed index and
hardware is very simple.
00:21:08.910 --> 00:21:13.560
We just simply rearrange
the order of the wires.
00:21:13.560 --> 00:21:20.620
To implement a bit reversed
index register or an index
00:21:20.620 --> 00:21:25.130
algorithmically is a little
more difficult. But in fact--
00:21:25.130 --> 00:21:28.570
and this is discussed in some
more detail in the text--
00:21:28.570 --> 00:21:31.450
one of the most
straightforward procedures,
00:21:31.450 --> 00:21:36.790
normally, is to
implement a bit reversed
00:21:36.790 --> 00:21:42.910
counter so that as we
proceed along with an index
00:21:42.910 --> 00:21:47.170
register accessing through
an index in normal order,
00:21:47.170 --> 00:21:51.730
we can also run a counter that
runs in bit reversed order
00:21:51.730 --> 00:21:56.110
and use, essentially, those two
as index registers to tell us
00:21:56.110 --> 00:21:57.910
how to swap the data.
00:21:57.910 --> 00:22:00.760
So a bit reversal, in
fact, algorithmically
00:22:00.760 --> 00:22:03.160
is relatively straightforward.
00:22:03.160 --> 00:22:07.600
It's an interesting point that
it is a somewhat inefficient
00:22:07.600 --> 00:22:14.860
procedure, as you'll see if you
try to program bit reversal.
00:22:14.860 --> 00:22:17.020
But algorithmically
and conceptually,
00:22:17.020 --> 00:22:21.920
it's a fairly straightforward
procedure to implement.
00:22:21.920 --> 00:22:24.750
A third computational
issue, which
00:22:24.750 --> 00:22:26.970
I would like to draw
your attention to
00:22:26.970 --> 00:22:34.830
is the question of obtaining the
coefficients to use in the FFT
00:22:34.830 --> 00:22:36.360
computation.
00:22:36.360 --> 00:22:39.360
And there are basically
two procedures
00:22:39.360 --> 00:22:42.600
that are commonly used.
00:22:42.600 --> 00:22:48.270
One, of course, is to store
the coefficients in a table
00:22:48.270 --> 00:22:53.220
and then simply access
them as they're needed.
00:22:53.220 --> 00:22:56.490
A second, which saves
storage but requires
00:22:56.490 --> 00:23:01.590
some computational time, is
to generate the coefficients
00:23:01.590 --> 00:23:03.090
recursively.
00:23:03.090 --> 00:23:04.950
That is essentially
using an oscillator--
00:23:04.950 --> 00:23:06.780
programming an oscillator--
00:23:06.780 --> 00:23:10.020
and generating the
coefficients as they're needed.
00:23:10.020 --> 00:23:12.810
Along those lines, it's
interesting to observe
00:23:12.810 --> 00:23:16.600
that in both the decimation
in time and decimation
00:23:16.600 --> 00:23:19.110
in frequency forms
of the algorithm,
00:23:19.110 --> 00:23:22.560
as you proceed from
stage to stage,
00:23:22.560 --> 00:23:28.170
the powers of W that are
involved in the computation
00:23:28.170 --> 00:23:34.380
are powers of a basic
power of W that doubles--
00:23:34.380 --> 00:23:35.970
or at least that changes--
00:23:35.970 --> 00:23:39.300
in each stage as you go
through the computation.
00:23:39.300 --> 00:23:43.380
And this has
implications as you think
00:23:43.380 --> 00:23:48.360
of either storing a table of
coefficients and accessing them
00:23:48.360 --> 00:23:53.850
or as you think of generating
the coefficients recursively.
00:23:53.850 --> 00:23:59.010
The fact that the powers of W
are related from stage to stage
00:23:59.010 --> 00:24:04.140
suggests some fairly efficient
procedures for doing this.
00:24:04.140 --> 00:24:10.850
One additional
consideration, though,
00:24:10.850 --> 00:24:18.950
in obtaining the
coefficients is that
00:24:18.950 --> 00:24:21.900
in some of the forms
of the FFT algorithm,
00:24:21.900 --> 00:24:29.040
the coefficients are naturally
accessed in a normal order,
00:24:29.040 --> 00:24:33.030
whereas in some other forms,
they are naturally accessed
00:24:33.030 --> 00:24:35.320
in a bit reversed order.
00:24:35.320 --> 00:24:41.250
For example, if we think of
the decimation in frequency
00:24:41.250 --> 00:24:45.750
form of the algorithm,
here is the decimation
00:24:45.750 --> 00:24:47.910
in frequency form
of the algorithm
00:24:47.910 --> 00:24:50.250
with the input in normal
order and the output in bit
00:24:50.250 --> 00:24:52.480
reversed order.
00:24:52.480 --> 00:24:59.430
Notice that the powers of W
that we have here occur in what
00:24:59.430 --> 00:25:01.440
looks like normal order.
00:25:01.440 --> 00:25:03.660
At least these powers
are in normal order.
00:25:07.830 --> 00:25:13.440
And this is normal input order,
bit reversed output order.
00:25:13.440 --> 00:25:17.690
Whereas if we took,
let's say, the decimation
00:25:17.690 --> 00:25:20.910
in time form of the algorithm--
00:25:20.910 --> 00:25:27.240
where we have normally ordered
input and bit reversed output--
00:25:27.240 --> 00:25:32.460
in that case, if you look
at these powers of W,
00:25:32.460 --> 00:25:33.960
they're not in normal order.
00:25:33.960 --> 00:25:37.860
In fact, what they're in
is bit reversed order.
00:25:37.860 --> 00:25:41.490
So in fact, in addition
to the consideration
00:25:41.490 --> 00:25:44.850
as to whether the
input is bit reversed
00:25:44.850 --> 00:25:49.020
or the output is bit reversed,
in some forms of the algorithm,
00:25:49.020 --> 00:25:54.300
the coefficients would tend
to be stored in normal order,
00:25:54.300 --> 00:25:57.090
whereas in some other
forms of the algorithm,
00:25:57.090 --> 00:25:58.770
the coefficients
would tend to be
00:25:58.770 --> 00:26:01.620
stored in a bit reversed order.
00:26:01.620 --> 00:26:04.860
Or if we think about
generating the coefficients,
00:26:04.860 --> 00:26:11.100
clearly it is simpler to think
of generating coefficients
00:26:11.100 --> 00:26:13.200
in normal order
than it is to think
00:26:13.200 --> 00:26:17.740
of them as being generated
in bit reversed order.
00:26:17.740 --> 00:26:23.920
Now with regard to the question
of the input and output
00:26:23.920 --> 00:26:29.590
being bit reversed, one
important area in which
00:26:29.590 --> 00:26:31.960
the computation of the DFT--
00:26:31.960 --> 00:26:34.300
in other words, the
FFT algorithms--
00:26:34.300 --> 00:26:40.540
play a role is in implementing
convolution or correlation.
00:26:40.540 --> 00:26:44.150
In that case, we
compute a transform,
00:26:44.150 --> 00:26:47.660
multiply by something-- in
the case of a convolution,
00:26:47.660 --> 00:26:54.080
we multiply by the transform
of the impulse response--
00:26:54.080 --> 00:26:56.680
and then implement
an inverse transform.
00:26:56.680 --> 00:27:00.010
Well the fact that there
are two transforms involved
00:27:00.010 --> 00:27:05.110
suggests the possibility that
we can organize the computation
00:27:05.110 --> 00:27:08.980
in such a way that we
completely avoid bit reversal.
00:27:08.980 --> 00:27:12.370
For example, we can
choose an algorithm
00:27:12.370 --> 00:27:15.730
for the direct
transform, which utilizes
00:27:15.730 --> 00:27:20.020
the input in normal order and
generates the transform in bit
00:27:20.020 --> 00:27:21.730
reversed order.
00:27:21.730 --> 00:27:24.070
We then simply
have the transform
00:27:24.070 --> 00:27:27.880
of the impulse response stored
in bit reversed order, carry
00:27:27.880 --> 00:27:31.210
out the multiplication,
and then choose
00:27:31.210 --> 00:27:35.410
a form of the algorithm for
the inverse transform, which
00:27:35.410 --> 00:27:39.190
has bit reversed
input and results
00:27:39.190 --> 00:27:42.200
in a normally ordered output.
00:27:42.200 --> 00:27:45.550
So in that case, what we would
have is the forward transform,
00:27:45.550 --> 00:27:48.080
normally ordered data
being transformed
00:27:48.080 --> 00:27:49.990
to bit reversed data.
00:27:49.990 --> 00:27:51.730
And then as the
inverse transform,
00:27:51.730 --> 00:27:55.280
bit reversed input and
normally ordered output.
00:27:55.280 --> 00:27:59.510
Well even given that, there are
a number of options available.
00:27:59.510 --> 00:28:03.190
For example, we
have an algorithm--
00:28:03.190 --> 00:28:06.590
the decimation in
time algorithm--
00:28:06.590 --> 00:28:09.445
which is normally ordered input.
00:28:12.070 --> 00:28:18.550
I'm sorry, normally ordered
input and bit reversed
00:28:18.550 --> 00:28:22.330
output, which we could use
as our forward transform.
00:28:22.330 --> 00:28:26.230
Although as we just
illustrated, it
00:28:26.230 --> 00:28:29.660
involves bit reversed
coefficients.
00:28:29.660 --> 00:28:32.680
Well we could think of storing
the coefficients in bit
00:28:32.680 --> 00:28:37.210
reversed order and then using
the companion decimation
00:28:37.210 --> 00:28:45.010
in time form of the algorithm,
which has bit reversed input
00:28:45.010 --> 00:28:51.790
and normally ordered output, to
achieve the inverse transform.
00:28:51.790 --> 00:28:54.250
However, in this
case the coefficients
00:28:54.250 --> 00:28:56.480
are in normal order.
00:28:56.480 --> 00:28:59.920
So if we match up the
algorithms that way,
00:28:59.920 --> 00:29:01.690
then we're faced
with the problem
00:29:01.690 --> 00:29:04.750
that in the direct transform,
the coefficients would
00:29:04.750 --> 00:29:07.870
be stored in bit
reversed order, whereas
00:29:07.870 --> 00:29:09.820
in the inverse
transform they would
00:29:09.820 --> 00:29:13.030
be stored in normal order.
00:29:13.030 --> 00:29:15.960
Well you can ask whether
for the decimation
00:29:15.960 --> 00:29:22.360
of frequency form of the
algorithm, we can avoid that.
00:29:22.360 --> 00:29:24.910
But in fact, the same
problem arises there.
00:29:24.910 --> 00:29:27.010
If we have the
decimation in time
00:29:27.010 --> 00:29:30.270
in frequency form of the
algorithm with normal input,
00:29:30.270 --> 00:29:34.390
bit reversed output,
then the coefficients
00:29:34.390 --> 00:29:37.360
are stored in normal order.
00:29:37.360 --> 00:29:44.170
But for the inverse decimation
in frequency transform with bit
00:29:44.170 --> 00:29:47.440
reversed input and
normally ordered output,
00:29:47.440 --> 00:29:52.060
the coefficients would be
stored in bit reversed order.
00:29:52.060 --> 00:29:55.550
The solution is to
match up a decimation
00:29:55.550 --> 00:29:59.800
in time form of the algorithm
with a decimation in frequency
00:29:59.800 --> 00:30:05.620
form of the algorithm
so that, for example,
00:30:05.620 --> 00:30:11.200
we can choose as the
forward transform
00:30:11.200 --> 00:30:18.220
the decimation in frequency form
of the algorithm with the input
00:30:18.220 --> 00:30:21.880
in normal order, the output
in bit reversed order,
00:30:21.880 --> 00:30:23.980
and the coefficients
normally ordered,
00:30:23.980 --> 00:30:27.340
which is generally
more convenient.
00:30:27.340 --> 00:30:32.650
And then choose for the inverse
transform not the decimation
00:30:32.650 --> 00:30:37.690
in frequency algorithm, but the
decimation in time algorithm,
00:30:37.690 --> 00:30:41.980
for which the input
is now bit reversed,
00:30:41.980 --> 00:30:47.050
the output is in normal
order, and the coefficients
00:30:47.050 --> 00:30:49.930
are also in normal order.
00:30:49.930 --> 00:30:55.930
So in fact, this suggests
that if we are implementing
00:30:55.930 --> 00:31:00.070
a forward transform and
an inverse transform,
00:31:00.070 --> 00:31:04.300
generally there are
advantages to matching up
00:31:04.300 --> 00:31:08.080
the decimation in time form
and the decimation in frequency
00:31:08.080 --> 00:31:12.190
form so that we have similarly
accessed coefficients
00:31:12.190 --> 00:31:14.200
in both cases.
00:31:14.200 --> 00:31:18.130
Well there are, of
course, a large variety
00:31:18.130 --> 00:31:20.350
of other computational
issues to be
00:31:20.350 --> 00:31:24.190
considered in implementing
the fast Fourier transform
00:31:24.190 --> 00:31:25.390
algorithms.
00:31:25.390 --> 00:31:28.240
Some of these are
discussed in the text.
00:31:28.240 --> 00:31:32.290
Many of them you will
discover for yourselves
00:31:32.290 --> 00:31:35.450
as you try to program
the algorithm.
00:31:35.450 --> 00:31:39.400
But hopefully, this
discussion provides
00:31:39.400 --> 00:31:44.320
at least some indication of
what some of the strategies are
00:31:44.320 --> 00:31:47.560
and some of the issues
are that are involved
00:31:47.560 --> 00:31:51.370
in computation of
the FFT of the forms
00:31:51.370 --> 00:31:53.790
that we've been talking about.
00:31:53.790 --> 00:31:57.830
Now all of this
discussion has been
00:31:57.830 --> 00:32:02.490
related to the computation
of the discrete Fourier
00:32:02.490 --> 00:32:06.770
transform when the number of
data points is a power of two.
00:32:06.770 --> 00:32:10.640
And these algorithms are
referred to as the radix two
00:32:10.640 --> 00:32:13.850
forms of the FFT algorithm.
00:32:13.850 --> 00:32:17.150
As I indicated in the first
lecture, in which we discussed
00:32:17.150 --> 00:32:21.860
the FFT, the FFT, in
fact, is more general
00:32:21.860 --> 00:32:25.940
in that it generally
applies when
00:32:25.940 --> 00:32:29.360
N is a highly composite number.
00:32:29.360 --> 00:32:32.780
We chose it to be
composed of powers of two.
00:32:32.780 --> 00:32:36.500
But in fact, there are
a variety of other forms
00:32:36.500 --> 00:32:40.350
of the FFT algorithm
for different radices.
00:32:40.350 --> 00:32:43.730
And in some cases, there
are some advantages
00:32:43.730 --> 00:32:47.690
to be found in using not
a power of two algorithm,
00:32:47.690 --> 00:32:51.290
but a different algorithm.
00:32:51.290 --> 00:32:53.390
On the other hand,
in many situations,
00:32:53.390 --> 00:32:56.810
the disadvantages of that
outweigh the advantages.
00:32:56.810 --> 00:33:00.380
However, what I would like to
do is conclude the discussion
00:33:00.380 --> 00:33:03.370
of the fast Fourier
transform algorithm
00:33:03.370 --> 00:33:12.320
by just very briefly outlining
what the structure of the FFT
00:33:12.320 --> 00:33:14.900
algorithm is more generally.
00:33:14.900 --> 00:33:19.940
And again, in the text
there are a number
00:33:19.940 --> 00:33:24.920
of examples of FFT
algorithms for radices
00:33:24.920 --> 00:33:28.350
other than a power of two and
a more complete discussion
00:33:28.350 --> 00:33:32.400
than I feel that is appropriate
to go through right now.
00:33:32.400 --> 00:33:37.400
However, let me just outline
what some of the issues
00:33:37.400 --> 00:33:44.930
are in discussing a more
general radix FFT algorithm.
00:33:44.930 --> 00:33:48.620
Generally the computation
of the discrete Fourier
00:33:48.620 --> 00:33:51.830
transform using this
class of algorithms
00:33:51.830 --> 00:33:55.430
is directed toward
capitalizing on the fact
00:33:55.430 --> 00:33:59.120
that the size transform
to be implemented
00:33:59.120 --> 00:34:02.840
is a product of numbers.
00:34:02.840 --> 00:34:07.880
And it turns out that
the more numbers--
00:34:07.880 --> 00:34:10.670
the more terms in
the decomposition--
00:34:10.670 --> 00:34:13.580
the greater the efficiency
that can be obtained
00:34:13.580 --> 00:34:16.600
in implementing the transform.
00:34:16.600 --> 00:34:20.420
In that case, generally one
would think of these numbers
00:34:20.420 --> 00:34:23.179
as primes, since
that is the biggest
00:34:23.179 --> 00:34:26.030
decomposition of any number
that we can carry out.
00:34:26.030 --> 00:34:30.469
But in fact, for the derivation,
it is not a requirement
00:34:30.469 --> 00:34:32.960
that the p's be primes.
00:34:32.960 --> 00:34:36.170
So let's think of N, then,
as decomposed as a product
00:34:36.170 --> 00:34:41.900
of p1 times p2, et
cetera, through p sub-Nu,
00:34:41.900 --> 00:34:47.630
which we can alternatively
write as p1 times q1,
00:34:47.630 --> 00:34:52.670
where q1 is then represented
by the product of the remaining
00:34:52.670 --> 00:34:54.889
terms.
00:34:54.889 --> 00:35:01.220
And we can proceed,
essentially, along a root
00:35:01.220 --> 00:35:06.830
similar to the decimation in
time algorithms or along a root
00:35:06.830 --> 00:35:09.890
similar to the decimation
in frequency algorithms.
00:35:09.890 --> 00:35:13.190
Let me just indicate
the strategy paralleling
00:35:13.190 --> 00:35:16.640
the decimation in time
form of the algorithm,
00:35:16.640 --> 00:35:20.490
as we discussed that
for N, a power of two.
00:35:20.490 --> 00:35:25.320
In that case, we decomposed
p1 is equal to two,
00:35:25.320 --> 00:35:28.140
and q1 is equal to N over two.
00:35:28.140 --> 00:35:31.560
And we decompose the
original sequence
00:35:31.560 --> 00:35:34.620
into two sub-sequences,
one consisting
00:35:34.620 --> 00:35:37.050
of the even numbered
points, the other consisting
00:35:37.050 --> 00:35:39.180
of the odd numbered points.
00:35:39.180 --> 00:35:43.170
More generally, we would
decompose the sequence
00:35:43.170 --> 00:35:51.820
into a set of sub-sequences
consisting of every p1th point.
00:35:51.820 --> 00:35:53.870
So how many sequences are there?
00:35:53.870 --> 00:35:56.950
Well, there are p1 sequences.
00:35:56.950 --> 00:36:00.370
And the length of
each sequence is q1.
00:36:00.370 --> 00:36:05.110
For example, if p1 was equal
to two, and q1 was N over two,
00:36:05.110 --> 00:36:07.284
this would be every other point.
00:36:07.284 --> 00:36:08.950
That's choosing the
even numbered points
00:36:08.950 --> 00:36:10.750
and the odd numbered points.
00:36:10.750 --> 00:36:13.720
There would be
two sub-sequences,
00:36:13.720 --> 00:36:17.820
each sub-sequence of
length N over two.
00:36:17.820 --> 00:36:22.920
More generally, then, if
we had, say, N equal to 12,
00:36:22.920 --> 00:36:32.220
and p1 equal to three, we would
generate three sub-sequences,
00:36:32.220 --> 00:36:38.970
each consisting of four points
chosen by selecting every p1th,
00:36:38.970 --> 00:36:40.590
or every third point.
00:36:40.590 --> 00:36:44.700
So one sub sequence, which
I've denoted here by A,
00:36:44.700 --> 00:36:48.520
would be this point and this
one and this one and that one.
00:36:48.520 --> 00:36:52.080
The second sub-sequence
would be the sub-sequence B,
00:36:52.080 --> 00:36:56.320
which is comprised of this
point, this, this, and that.
00:36:56.320 --> 00:36:59.640
And the third sub-sequence
would be sub-sequence
00:36:59.640 --> 00:37:02.220
C, which is this point,
this point, that point,
00:37:02.220 --> 00:37:04.830
and that point.
00:37:04.830 --> 00:37:08.190
All right, so we decompose
the original sequence, then,
00:37:08.190 --> 00:37:13.020
into p1 sequences,
each of length q1.
00:37:13.020 --> 00:37:17.190
Given that, we can
organize the sum involved
00:37:17.190 --> 00:37:21.240
in the discrete
Fourier transform
00:37:21.240 --> 00:37:26.040
by decomposing the sum
into separate sums,
00:37:26.040 --> 00:37:32.600
involving each one of
these p1 sub-sequences.
00:37:32.600 --> 00:37:38.360
In particular, if we think
of the argument p1 times
00:37:38.360 --> 00:37:46.235
r, as r ranges from
zero to q1 minus one,
00:37:46.235 --> 00:37:50.930
we're selecting, with this
argument, every p1th point,
00:37:50.930 --> 00:37:54.470
starting with the
zero-eth point.
00:37:54.470 --> 00:37:57.890
If we think of the
argument p1 r plus one,
00:37:57.890 --> 00:38:00.740
as r runs from zero
to q1 minus one,
00:38:00.740 --> 00:38:04.640
we're then collecting
together the terms,
00:38:04.640 --> 00:38:08.680
which are every p1th point,
starting with the first point.
00:38:08.680 --> 00:38:12.740
Et cetera, we can
proceed to decompose this
00:38:12.740 --> 00:38:20.030
into a set of p1 sub-sums,
as I've indicated here.
00:38:20.030 --> 00:38:22.460
Or when we combine
these together,
00:38:22.460 --> 00:38:27.740
then, we can express
x of k, the DFT,
00:38:27.740 --> 00:38:36.000
as a double sum, where we
have the terms involving
00:38:36.000 --> 00:38:41.130
the separate sub sequences
and then the multiplication
00:38:41.130 --> 00:38:46.260
by a power of W to
combine the computation
00:38:46.260 --> 00:38:50.430
on these sub-sequences
together to obtain the DFT.
00:38:50.430 --> 00:38:53.940
These terms, of course,
are obtained by the fact
00:38:53.940 --> 00:38:57.730
that this power of
W is p1 r plus one.
00:38:57.730 --> 00:39:01.200
In the next sum, it will be p1
r plus two, p1 r plus three,
00:39:01.200 --> 00:39:02.220
et cetera.
00:39:02.220 --> 00:39:07.050
We decompose that into a
product of two powers of W.
00:39:07.050 --> 00:39:10.620
And then one of those terms--
00:39:10.620 --> 00:39:12.390
since it doesn't
depend on r-- can
00:39:12.390 --> 00:39:17.051
be removed from the sum on r
and shows up in this second sum.
00:39:17.051 --> 00:39:18.630
Well I would suggest--
00:39:18.630 --> 00:39:20.640
that's a somewhat
rapid treatment--
00:39:20.640 --> 00:39:22.740
I would suggest
just simply working
00:39:22.740 --> 00:39:24.010
through that for an example.
00:39:24.010 --> 00:39:28.290
And I think it will be clear how
this original sum is decomposed
00:39:28.290 --> 00:39:31.180
into this one.
00:39:31.180 --> 00:39:35.140
All right, well now, just as
we did in both the decimation
00:39:35.140 --> 00:39:37.480
in time and decimation
in frequency forms
00:39:37.480 --> 00:39:41.710
of the algorithm
for powers of two,
00:39:41.710 --> 00:39:47.320
we can recognize
this power of W sub-N
00:39:47.320 --> 00:39:53.830
as a different power of a W
with a different subscript.
00:39:53.830 --> 00:40:00.760
In particular, W sub-N to
the p1 rk, as I have here,
00:40:00.760 --> 00:40:06.730
is equal to e to the j two pi
over capital-N times p1 rk.
00:40:06.730 --> 00:40:12.310
But N is equal to p1 times q1.
00:40:12.310 --> 00:40:15.670
That's the way we
originally decomposed it.
00:40:15.670 --> 00:40:19.210
And the p1's cancel out.
00:40:19.210 --> 00:40:22.690
And we're left with e to
the j two pi over q1 times
00:40:22.690 --> 00:40:29.680
rk or equivalently,
W sub-q1 to the rk.
00:40:29.680 --> 00:40:36.490
So substituting this
for W sub-N to the p1 r
00:40:36.490 --> 00:40:42.490
k in the previous expression,
what results is then x of k
00:40:42.490 --> 00:40:46.960
expressed as a sum from l
equals zero, p1 minus one,
00:40:46.960 --> 00:40:50.650
of these powers of
W sub-N. But then
00:40:50.650 --> 00:40:56.620
the important thing is that
the inner sum involves q1 point
00:40:56.620 --> 00:40:59.240
sequences.
00:40:59.240 --> 00:41:02.710
This factor is W
sub-q1 to the rk.
00:41:02.710 --> 00:41:09.730
And in fact, this entire
summation is a q1 point DFT.
00:41:09.730 --> 00:41:14.790
So pursuing this, then,
what we basically decomposed
00:41:14.790 --> 00:41:24.100
the computation into is the
computation of p1 q1 point
00:41:24.100 --> 00:41:26.890
DFT's.
00:41:26.890 --> 00:41:30.970
We obtained the q1 point
DFT's and then combined them,
00:41:30.970 --> 00:41:34.900
according to the
expression as we have here.
00:41:34.900 --> 00:41:38.380
This would then lead to the
generalization of the butterfly
00:41:38.380 --> 00:41:43.780
computation as we had it for
the radix two algorithms.
00:41:43.780 --> 00:41:47.290
And if you count up the
number of multiplies and adds,
00:41:47.290 --> 00:41:51.130
again, you'll see that there is
some computational efficiency
00:41:51.130 --> 00:41:53.380
that results from doing this.
00:41:53.380 --> 00:41:57.580
And then, just as we did with
the radix two algorithms,
00:41:57.580 --> 00:42:02.590
we can continue to
decompose these transforms
00:42:02.590 --> 00:42:09.310
so that we have q1 is given
by the product p2 times p3
00:42:09.310 --> 00:42:11.560
through p sub-Nu.
00:42:11.560 --> 00:42:16.990
This product we denote as q2.
00:42:16.990 --> 00:42:22.030
And then we can proceed to
decompose these transforms--
00:42:22.030 --> 00:42:25.270
these q1 point transforms--
00:42:25.270 --> 00:42:30.610
into p2 q2 point transforms.
00:42:30.610 --> 00:42:34.570
Then we can decompose the q2
point transforms, et cetera.
00:42:34.570 --> 00:42:37.330
If you do this, then
what you'll find--
00:42:37.330 --> 00:42:40.030
and the counting is done
a little more carefully
00:42:40.030 --> 00:42:42.160
in the text--
00:42:42.160 --> 00:42:46.360
what you'll find is that the
number of multiplies and adds
00:42:46.360 --> 00:42:50.440
involved in computing the
discrete Fourier transform
00:42:50.440 --> 00:42:59.080
this way is proportional to
N times a sum of the factors
00:42:59.080 --> 00:43:03.660
involved in the
decomposition of N.
00:43:03.660 --> 00:43:07.630
I've indicated an additional
factor here of minus Nu.
00:43:07.630 --> 00:43:11.620
Depending on how you choose
to count multiplies and adds,
00:43:11.620 --> 00:43:15.130
this factor of minus Nu
either shows up or not.
00:43:15.130 --> 00:43:20.660
In fact, to make this
expression consistent with what
00:43:20.660 --> 00:43:25.340
we obtained for the
power of two algorithms,
00:43:25.340 --> 00:43:27.470
the minus Nu should be in here.
00:43:27.470 --> 00:43:30.680
And it's simply a
question of whether you
00:43:30.680 --> 00:43:34.730
count or don't count some
multiplications by unity.
00:43:34.730 --> 00:43:39.110
Well OK, that's a very quick
treatment-- discussion--
00:43:39.110 --> 00:43:43.520
of the generalization of
the radix two algorithms
00:43:43.520 --> 00:43:45.800
to more arbitrary radix.
00:43:45.800 --> 00:43:49.490
And there, as I indicated,
are some examples
00:43:49.490 --> 00:43:52.730
of this, which are
given in the text.
00:43:52.730 --> 00:43:55.580
Although, in fact,
what you'll find
00:43:55.580 --> 00:43:58.850
is that in most
practical contexts,
00:43:58.850 --> 00:44:05.480
it is a radix two algorithm that
is the most efficient to use.
00:44:05.480 --> 00:44:09.620
And I indicate,
incidentally, that if you
00:44:09.620 --> 00:44:13.370
are faced with the problem
of transforming data, which
00:44:13.370 --> 00:44:16.610
is of a length which is not
a power of two, it of course
00:44:16.610 --> 00:44:20.180
can always be made to be
of length power of two
00:44:20.180 --> 00:44:24.470
by simply augmenting
the sequence with zeros.
00:44:24.470 --> 00:44:29.480
Well this concludes, then,
the discussion of the FFT
00:44:29.480 --> 00:44:35.120
algorithms, the computation of
the discrete Fourier transform.
00:44:35.120 --> 00:44:40.280
And there are, I hope,
a number of issues
00:44:40.280 --> 00:44:43.550
which you will
have an opportunity
00:44:43.550 --> 00:44:46.700
to dwell on some as you
read through the text
00:44:46.700 --> 00:44:50.330
and as your attention will be
drawn to in the study guide.
00:44:50.330 --> 00:44:50.870
Thank you.
00:44:54.770 --> 00:44:56.920
[MUSIC PLAYING]