Shop OBEX P1 Docs P2 Docs Learn Events
Some CORDIC documentation - Page 5 — Parallax Forums

Some CORDIC documentation

1235»

Comments

  • Graham StablerGraham Stabler Posts: 2,507
    edited 2007-04-21 20:00
    Struggle 1:

    Generally in a binary fraction the msb equals 1/2 then the next less significant bit equals 1/4 and so on. One is therefore obtained when all bits are one.

    For the whole combination to be one the number should be

    00100000_00000000_00000000_00000000

    Sign is 0
    The integral is one
    The fraction is zero.

    Struggle 2:

    I don't understand what the L represents in the line

    #define One (010000000000L>>1)

    Nor can I imagine why the shift is used which leads me to suspect all it not as it seems, I suspect the result of this strange operation may be what I suggest in part 1.

    To understand the basic concepts I found a mix of wikipedia and Tracy's site good after that having a go even with floats in excel was helpfull. You can see from the link Tracy has just posted the question of "what is one" is key in some cases.

    Graham
  • WulffyWulffy Posts: 11
    edited 2007-04-22 14:20
    Tracy Allen said...
    Wuffy,

    Did you also read this thread, Cordic Object, and also look at the reference there to Turner's book that has code in Matlab.

    Often the core algorithm is implemented to cover the domain of convergence only, and then a wrapper is needed that will extend the domain of validity to a range appropriate to a particular application. That way you can get either speed or generality, two qualities that are often in conflict.

    Yeah, I read that thread, and have the chapter referenced therein.· Thanks for pointing that out.· The concept of convergence is escaping me at the moment.· This whole exercise is humbling... :-)
  • WulffyWulffy Posts: 11
    edited 2007-04-22 15:16
    Graham Stabler said...
    Struggle 1:

    Generally in a binary fraction the msb equals 1/2 then the next less significant bit equals 1/4 and so on. One is therefore obtained when all bits are one.

    For the whole combination to be one the number should be

    00100000_00000000_00000000_00000000

    Sign is 0
    The integral is one
    The fraction is zero.


    I concur with your assessment regarding the sign, integral, and mantissa(fraction).· I am guessing that I will need to continue to be a bit more of a sponge, before I can truly grasp the implementation of the manipulation of the fractional bits.· Regardless, Thanks.

    Struggle 2:

    I don't understand what the L represents in the line - Neither do I... [noparse]:)[/noparse] I am suspecting that it is a directive operand that is used to denote a long, but that is speculation.· I have looked at a manual for C as well as the C Preprocessor, to get it set in stone what it means, but it has not yet bubbled to the surface.

    #define One (010000000000L>>1)

    Nor can I imagine why the shift is used which leads me to suspect all it not as it seems, I suspect the result of this strange operation may be what I suggest in part 1.·- I fully concur regarding your suspicions.· The logic of it escapes me as well, and causes me to be a bit suspect.

    To understand the basic concepts I found a mix of wikipedia and Tracy's site good after that having a go even with floats in excel was helpfull. You can see from the link Tracy has just posted the question of "what is one" is key in some cases. - I'll continue to absorb.· I love the concept of having a library that facilitates having a dynamic representation of ONE.· i.e. for those calculations where the·the values being manipulated·are large integers, a 0100 being representative of·ONE allows the majority of the variable's bit space to be representative of the integral, where as a value of 01000000000 would allow for much higher precision (and of course,·smaller integral representations...).

    Graham
    My approach to date, has been trying to find a library that would lend itself to porting to my platform with minimal understanding required of what is actually transpiring - i.e. the easy way out...
    I am finding that·any implementation is actually heavily predicated on a full and finite understanding of the algorithm's mechanics,·having to have a working solution for·handling non-integer·numeric representation in a non-float environment, as well as the limitation on operands that are available in a lower level BASIC implementation.·
    Some of the source code out there - i.e. Peter's Java Implementation, or the source I attached, employs concepts specific to environments that I am not familiar with nor operating in.· Not having programmed in an OOP environment before, lends itself to looking at a hunk of code, and initially thinking that it's translation to my environment would be easily accomplished, only to realize that concepts such as recursion, scope, and operator overloading·serve to truly muddy the waters (at least for me... :-).··Not being able to pass/return parameters, but rather having to use·global variables serves to confuse things further as well, during my porting attempts to date.
    I think my initial approach·was/is flawed.· I am finally relegating myself to the fact that I must grasp the CORDIC principles first, in detail·(which require an understanding of the underlying trigonometric fundamentals - it has been a lot of years since high-school·:-), and then use the various works available as a frame of reference when drafting my own CORDIC engine...
    I·know that when I am am done, I will appreciate what goes into developing same...
    At any rate, thank you all for your assistance thus far.· I think I'll give Tracy's code one more shot at porting (yes, I am being lazy...rolleyes.gif)
    -t

    ·
  • Graham StablerGraham Stabler Posts: 2,507
    edited 2007-04-22 15:59
    Well if I can manage to finish my cordic object then you won't need to understand it to use it but an understanding of the number representations on input and output will be required, I was hoping to explain these with many examples in the demo code.

    Graham
  • Peter VerkaikPeter Verkaik Posts: 3,956
    edited 2007-04-22 16:42
    Graham,
    In C, numbers starting with 0, are octal.
    A suffix L identifies a long (32bits).
    010000000000L>>1 = 001_000_000_000_000_000_000_000_000_000_000>>1 (bin)
    ················ = 000_100_000_000_000_000_000_000_000_000_000
    ················ =· 00_100_000_000_000_000_000_000_000_000_000
    ················ = 0010_0000_0000_0000_0000_0000_0000_0000 (bin)
    ················ = 2000_0000 (hex)

    So you got the number right.

    regards peter
  • WulffyWulffy Posts: 11
    edited 2007-04-22 17:33
    Peter Verkaik said...
    Graham,
    In C, numbers starting with 0, are octal.
    ...
    Doh! shocked.gif
    Oh my, sometimes we can't see the forest through the trees - this is too funny - Peter, Thank you for showing me the errors of my ways in that... ROTFL tongue.gif

    Post Edited (Wulffy) : 4/22/2007 5:37:40 PM GMT
  • Graham StablerGraham Stabler Posts: 2,507
    edited 2007-04-23 08:53
    This demonstrates the problem with search engines, exactly what would I have searched for to find this information "confusing #define with an L and it happens to start with a zero if that makes any difference not that I have any reason to think it does" [noparse]:)[/noparse]

    Thanks Peter!

    Graham
  • Peter VerkaikPeter Verkaik Posts: 3,956
    edited 2007-04-23 09:20
    Octal numbers in C are one of the lesser attractive syntax.
    They (Kernighan and Ritchie) should have used 0o.... for octal, as they use 0x.... for hexadecimal.
    Then also 0b.... should be used for binary (some C's actually have this, others use %.... for binary).

    The suffix L is a short notation for typecast to long
    1L equals (long)1
    I guess you just need to know these things, but if you're not into C, it is confusing.

    regards peter
Sign In or Register to comment.