Creating an array whose DFT is all whole numbers I'm working on a simple FFT implementation and currently running some unit tests. Long floating point numbers in C and assembly become very hard to keep track of, and this whole thing is error prone. I was able to some up (purely experimentally) with a few 4-tap and 8-tap arrays whose DFT is all whole numbers. I'm only testing DFT arrays of length $2^N$, and I could, of course, repeat my shorter signals several times until I achieve desired length, but this would give me a whole bunch of zeros, and that's not a good thing to test for. In summary, I need to come up with signals that satisfy the following:


Signals are of length $2^N$
Coefficients of both the signal and its DFT must be whole numbers
Signals are real
Signals must not consist mainly of zeros


Could there be a general way of coming up with such things?

Update
To explain number 4 above, let me demonstrate what I mean with an example. I don't want a situation in that was produced by repeating something that has a known integer DFT several times.DFT of [1 5 -1 0] is [5 2-5i -5 2+5i]. If you simply repeat [1 5 -1 0] four times to get

[1 5 -1 0 1 5 -1 0 1 5 -1 0 1 5 -1 0],

its DFT would be 

[20 0 0 0 8-20i 0 0 0 -20 0 0 0 8+20i 0 0 0].

This shows that repeating something many times does not add any new non-zero integer numbers to the DFT. This procedure simply inserts zeros between existing DFT coefficients (and scales them depending on definition of the transform). This isn't of much help. So zeros are welcome, but not the zeros achieved this way.
The DFT matrix has $e^\frac{-2 \pi j}{2^N}$ as coefficients. For $N &gt;= 3$, these coefficients might have irrational numbers as real/imaginary parts (eg $\frac{\sqrt 2}{2}$ for $N=3$); so all these irrational terms will have to cancel out exactly in the DFT computation. There are ways of achieving that (repeating is one of them) ; but this keeps you away from the general case that your code has to test! For example, this will create symmetries in your data that might make an error in the bit reversal, or in the higher orders (3rd level or above) of butterflies undetected!

Another thing to take into account is that due to the pure floating point implementation, even if the expected result should be a whole number, your FFT code, especially on large sizes, might find a result like 0.99999999 (Heck, some whole numbers are not even representable as floats!) ; and this wouldn't be incorrect. Plausible on doubles, very likely of floats.

So you'd rather use very generic data (ie: that will yield some irrational numbers) ; and some unit tests that guarantees you that your results are within some tolerance of values computed by a reference implementation such as FFTW. For example in gtest there is EXPECT_FLOAT_EQ or EXPECT_NEAR to check for float equality (up to representation errors) and for float equality given a tolerance.