fft in fpga using polar form

i understand that representing large number of twiddle factors that are req=
uired in a fft with large number of points is an issue when using fixed poi=
nt scheme. To my understanding (which could be very wrong as i am new to th=
is),the issue is large dynamic range that is needed to represent real and i=
maginary parts of the complex numbers. Would the use of polar form to repre=
sent them solve this problem, as for all twiddle factors, the absolute valu=
e will be one and the argument will change from 0 to 360? (or should the ar=
gument be specified in radians always?)

jack.pett.son@gmail.com wrote:
> i understand that representing large number of twiddle factors 
> that are required in a fft with large number of points is an 
> issue when using fixed point scheme. 

As far as I know, that isn't a problem. 

> To my understanding 
> (which could be very wrong as i am new to this),the issue is 
> large dynamic range that is needed to represent real and 
> imaginary parts of the complex numbers. 

No matter how you do it, you can't have a large dynamic
range with the FFT. (Or, even worse usually, the non-fast
DFT.) Enough addition and subtraction is done that the 
dynamic range is pretty much whatever precision the computation
is done at.

> Would the use of 
> polar form to represent them solve this problem, as for 
> all twiddle factors, the absolute value will be one and 
> the argument will change from 0 to 360? 

I don't believe that helps. For the usual twiddle factors,
all you need is a small (or big) lookup table. In polar
coordinates, with any angular measure, you need to compute
sines and cosines at each step.

Well, if all you needed to do was rotations in polar 
coordinates, then yes. But you also have to add and subtract
values at different rotations.

> (or should the argument be specified in radians always?)

More obvious to me, binary fractions of a whole rotation.

-- glen

jack.pett.son@gmail.com wrote:
> Would the use of polar form to represent them solve this problem?

Which reminds me of a different question I have wondered
about for a while: 

Why do so few high-level languages provede trigonometric
functions in degrees in their math libraries?

The only one I know of is PL/I, not so commonly used these days.

I know the reasons for doing trigonometry in radians, and have
no complaint against doing it in radians, but reasonably often it
is convenient to do in a unit that is a rational fraction of a 
whole rotation.

Now, the same arguments against degrees could be used against
supplying a log10 function, but many systems do supply that one.

Usually the first thing that non-inverse trigonometric routines
do is argument reduction after dividing by some multiple of pi.
If one actually wants a nice fraction of a whole circle, it is
extra work and precision loss to multiply by some multiple of pi
just before the routine divides by a multiple of pi.

-- glen