Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!zephyr.ens.tek.com!orca!ka7axd.WV.TEK.COM!mhorne
From: mhorne@ka7axd.WV.TEK.COM (Michael T. Horne)
Newsgroups: comp.dsp
Subject: Re: FFT for integer data
Message-ID: <4842@orca.WV.TEK.COM>
Date: 5 Oct 89 15:48:15 GMT
References: <2620@pur-phy>
Sender: nobody@orca.WV.TEK.COM
Reply-To: mhorne@ka7axd.wv.tek.com
Organization: Horne's Happy Home of Heavy Hacking
Lines: 23

> 2.)  ...Is there
>      any acceleration available for strictly integer data input versus
>      real input to the FFT routine? i.e. is there an optimization available
>      for integer data?  I assume that regardless of input you will return
>      a real complex spectrum instead of an integer complex spectrum?

You can implement an all-integer FFT by storing your data and sin/cos terms
as scaled integers (i.e. scale all data up some number of bits to preserve
`fractional' results).  I've implemented just such an algorithm, and as long
as you take care in avoiding overflow, it works fine.  One suggestion, however;
Use as many bits as possible to store your data and sin/cos values
so you have sufficient dynamic range.  Using 32-bit integers will provide
reasonable results (depending, of course, on the number of bits of resolution
your original data has).  16-bit integers probably won't provide you with
sufficient dynamic range.  If you're using an 80x86 based box with only 16-bit
registers, you'll have to 1) accept the small word size in exchange for speed,
or 2) do 32-bit math with < 1/2 the speed of 16-bit math.  If you're using a
32-bit processor, then you're in good shape.

>--
>  Bill Murphy        murphy@newton.physics.purdue.edu

Mike