DSPRelated.com
Forums

C code for fixed point atan2

Started by Eric Meurville January 20, 2005
In article <1106327897.743543.57540@z14g2000cwz.googlegroups.com>,
 <bungalow_steve@yahoo.com> wrote:
>> Who said anything about using integers. I said fixed point.
...
>There is a fixed point data type in C?
Yes, indirectly. The meaning of the bits in (int/short/long) are defined by the programmer. For instance they can represent boolean flags instead of any scalar quantity. If LSB represents a unit quantity, then you might have traditional integers. But the LSB can also represent a fractional quantity, for instance, cents instead of dollars if you don't want to lose pennies in certain types of financial arithmetic. The LSB can also represent 1/256th's, or other 1/(2^n)th's, if you want normalization or renormalization to be easily done using the << and >> C operators. Normalize for any input or output, and renormalize after any multiply or divide, and the (int/short/long) C data types can be used to represent fixed point or scaled integer values of the appropriate range and accuracy. IMHO. YMMV. -- Ron Nicholson rhn AT nicholson DOT com http://www.nicholson.com/rhn/ #include <canonical.disclaimer> // only my own opinions, etc.
Ronald H. Nicholson Jr. wrote:
(someone asked)

>>There is a fixed point data type in C?
> Yes, indirectly. The meaning of the bits in (int/short/long) are > defined by the programmer. For instance they can represent boolean flags > instead of any scalar quantity. If LSB represents a unit quantity, then > you might have traditional integers. But the LSB can also represent a > fractional quantity,
It would be much easier with a multiply that returned a 2N bit product, and a divide that took a 2N bit dividend. That is the way it is done in hardware, mostly for this reason. (The other reason is to allow implementing multiple precision arithmetic.) -- glen
This is a multi-part message in MIME format.
--------------020006080406080906020401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ronald H. Nicholson Jr. wrote:

>In article <1106327897.743543.57540@z14g2000cwz.googlegroups.com>, > <bungalow_steve@yahoo.com> wrote: > > >>>Who said anything about using integers. I said fixed point. >>> >>> >... > > >>There is a fixed point data type in C? >> >> > >Yes, indirectly. The meaning of the bits in (int/short/long) are >defined by the programmer. For instance they can represent boolean flags >instead of any scalar quantity. If LSB represents a unit quantity, then >you might have traditional integers. But the LSB can also represent a >fractional quantity, for instance, cents instead of dollars if you don't >want to lose pennies in certain types of financial arithmetic. The LSB can >also represent 1/256th's, or other 1/(2^n)th's, if you want normalization >or renormalization to be easily done using the << and >> C operators. > >Normalize for any input or output, and renormalize after any multiply >or divide, and the (int/short/long) C data types can be used to represent >fixed point or scaled integer values of the appropriate range and accuracy. > >IMHO. YMMV. > >
I think it is interesting to note that various older languages - Algol, Coral, PL/1 - had explicit support for fixed point arithmetic. I think Ada still does (its years since I touched it), but it seems to be missing for other currently popular languages. Its value was somewhat limited in the older languages. It was generally rather implementation dependant, so code tended not to be very portable. It is, however, something of a pity that you now have to use vanilla integers, and do all the fiddley bits yourself. You may end up with the same result, but the code lacks clarity. That said, if you can't see that any language supporting integers also supports fixed point you've failed arithmetic 101. :-) Regards, Steve --------------020006080406080906020401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Ronald H. Nicholson Jr. wrote: <blockquote cite="midcsrko3$u8c$1@blue.rahul.net" type="cite"> <pre wrap="">In article <a class="moz-txt-link-rfc2396E" href="mailto:1106327897.743543.57540@z14g2000cwz.googlegroups.com">&lt;1106327897.743543.57540@z14g2000cwz.googlegroups.com&gt;</a>, <a class="moz-txt-link-rfc2396E" href="mailto:bungalow_steve@yahoo.com">&lt;bungalow_steve@yahoo.com&gt;</a> wrote: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Who said anything about using integers. I said fixed point. </pre> </blockquote> </blockquote> <pre wrap=""><!---->... </pre> <blockquote type="cite"> <pre wrap="">There is a fixed point data type in C? </pre> </blockquote> <pre wrap=""><!----> Yes, indirectly. The meaning of the bits in (int/short/long) are defined by the programmer. For instance they can represent boolean flags instead of any scalar quantity. If LSB represents a unit quantity, then you might have traditional integers. But the LSB can also represent a fractional quantity, for instance, cents instead of dollars if you don't want to lose pennies in certain types of financial arithmetic. The LSB can also represent 1/256th's, or other 1/(2^n)th's, if you want normalization or renormalization to be easily done using the &lt;&lt; and &gt;&gt; C operators. Normalize for any input or output, and renormalize after any multiply or divide, and the (int/short/long) C data types can be used to represent fixed point or scaled integer values of the appropriate range and accuracy. IMHO. YMMV. </pre> </blockquote> I think it is interesting to note that various older languages - Algol, Coral, PL/1 - had explicit support for fixed point arithmetic. I think Ada still does (its years since I touched it), but it seems to be missing for other currently popular languages. Its value was somewhat limited in the older languages. It was generally rather implementation dependant, so code tended not to be very portable. It is, however, something of a pity that you now have to use vanilla integers, and do all the fiddley bits yourself. You may end up with the same result, but the code lacks clarity.<br> <br> That said, if you can't see that any language supporting integers also supports fixed point you've failed arithmetic 101. :-)<br> <br> Regards,<br> Steve<br> <br> </body> </html> --------------020006080406080906020401--
Steve Underwood wrote:
> Ronald H. Nicholson Jr. wrote: > > >In article <1106327897.743543.57540@z14g2000cwz.googlegroups.com>, > > <bungalow_steve@yahoo.com> wrote: > > > > > >>>Who said anything about using integers. I said fixed point. > >>> > >>> > >... > > > > > >>There is a fixed point data type in C? > >> > >> > > > >Yes, indirectly. The meaning of the bits in (int/short/long) are > >defined by the programmer. For instance they can represent boolean
flags
> >instead of any scalar quantity. If LSB represents a unit quantity,
then
> >you might have traditional integers. But the LSB can also represent
a
> >fractional quantity, for instance, cents instead of dollars if you
don't
> >want to lose pennies in certain types of financial arithmetic. The
LSB can
> >also represent 1/256th's, or other 1/(2^n)th's, if you want
normalization
> >or renormalization to be easily done using the << and >> C
operators.
> > > >Normalize for any input or output, and renormalize after any
multiply
> >or divide, and the (int/short/long) C data types can be used to
represent
> >fixed point or scaled integer values of the appropriate range and
accuracy.
> > > >IMHO. YMMV. > > > > > I think it is interesting to note that various older languages -
Algol,
> Coral, PL/1 - had explicit support for fixed point arithmetic. I
think
> Ada still does (its years since I touched it), but it seems to be > missing for other currently popular languages. Its value was somewhat
> limited in the older languages. It was generally rather
implementation
> dependant, so code tended not to be very portable. It is, however, > something of a pity that you now have to use vanilla integers, and do
> all the fiddley bits yourself. You may end up with the same result,
but
> the code lacks clarity. > > That said, if you can't see that any language supporting integers
also
> supports fixed point you've failed arithmetic 101. :-) > > Regards, > Steve
Exactly my point when I responsed to your "Who said anything about using integers. I said fixed point." post
I always thought that the standard fixed-point formats like Qm,n format
would work fine with this as it is a case of polynomial evaluation,
although i am not sure about the accuracy you need. You may use
somehing like Horner's rule for evaluating the polynomial.

but when you do go for the higher order polynomial i fixed-point
implementation then you may run into problems like representation of
the smaller values, 'underflow saturation' (i mean the saturation to
the negative number representable closest to zero)etc...


Well, i would like to hear from other experts if i am wrong here.

-Nithin

Eric Meurville wrote:
> Thanks for the link but the code proposed uses floats and I would > perform the computation with integers. > > EMe. > > Nithin wrote: > > Hi > > You may want to look a this > > http://dspguru.com/comp.dsp/tricks/alg/fxdatan2.htm > > > > -Nithin > >
In article <1106610330.387624.141080@z14g2000cwz.googlegroups.com>,
Nithin <nitin_hsn@yahoo.com> wrote:
>I always thought that the standard fixed-point formats like Qm,n format >would work fine with this as it is a case of polynomial evaluation, >although i am not sure about the accuracy you need. You may use >somehing like Horner's rule for evaluating the polynomial. > >but when you do go for the higher order polynomial i fixed-point >implementation then you may run into problems like representation of >the smaller values, 'underflow saturation' (i mean the saturation to >the negative number representable closest to zero)etc...
Don't forget that one can use a different fixed-point representation for intermediate values, either by moving the binary-point (changing the m/n ratio of [Qm,n]), or by switching the C data type used to hold the fixed-point representation (from short to long to long long to even larger C structs). On hardware without an FPU even using multiprecision fixed-point structs might still be faster than switching to using some floating-point libraries. When using HDL's (hardware languages) for FPGA's and ASIC's, it's common to use a bit-width and fractional representation specific for each and every operand and intermediate value of a dedicated single-function DSP data-path (why generate wider paths, with more gates, slower carry-logic, longer wires, requiring more power, etc., than required, assuming the development and test schedule allows this optimization). IMHO. YMMV. -- Ron Nicholson rhn AT nicholson DOT com http://www.nicholson.com/rhn/ #include <canonical.disclaimer> // only my own opinions, etc.
Hello Eric,
If you know about the CORDIC algorithm, it is easy to implement atan2
in fixed point arithmetic.
In case you are having difficulty finding the algo on the web, let me
know. I shall keep u updated on this.

Regards,
Suren

Hello Suren,

I am please to accept your help as it seems that CORDIC matches 
perfectly my requirements. I tried to find out pieces of code related to 
CORDIC I would be able to implement on dsPIC30 but without success. It 
would be very helpful if you could provide me with an update about CORDIc.

Thanks in advance and Regards.

Eric.

suren wrote:
> Hello Eric, > If you know about the CORDIC algorithm, it is easy to implement atan2 > in fixed point arithmetic. > In case you are having difficulty finding the algo on the web, let me > know. I shall keep u updated on this. > > Regards, > Suren >
Hi
If the dynamic range of input valus is large then does'nt CORDIC take
more cycles when compared to the polynomial method? Please correct me
if iam wrong. I guess a standard point (usually 1) is used as a
starting point for CORDIC usually. 
-Nithin

If you have specific questions let me know - I am the original author
of the atan2 algorithm on dspguru.

And the guys here are correct, the C code is easily converted to
fixed-pt.  In fact it was first implemented in fixed-pt assembly, but
publishing DSP assembly code probably wouldnt get the point across to a
wide audience - hence the santized C version.