The former has my attempts at understanding with some code the second is about my cordic engine which was some code designed to do pretty much all the mathematic operations using cordic. There is some code posted but I am not sure I posted or even finished the object.
Yikes!!AfterreadingtheabovetwolinksIappreciateevenmoretheworkthatBeandidtalkaboutgobbledeegookandobsfucationdomainthisandmatrixthateeegads.
Thank you once again Bean, You go dude!
Bean,
The improved document is great, thanks! Glad you added the SIN/COS stuff.
However, I noticed in your code example, you use the arithmetic shift right operator (~>) this doesn't work fully correctly for negative numbers. It won't shift a negative number down to 0. In cases where you want it to shift all the way down to 0, it'll end up with a -1.
In my example code posted above I showed a way to get around that. It also has my attempt at explaining the issue and the work around in the comments.
Roy, that's a nice way to handle the ~> issue. In my experience, however, the issue doesn't bite me, as I never go for a full 32-bits' worth of accuracy. In F32 I prescale my vector, do 25 iterations (as float 32 uses 24 bits of mantissa), then use the result. So, I start with a 30-bit number, get about 25 significant bits, leaving about 5 insignificant bits down at the bottom. In that scenario, a 0 masquerading as a -1 doesn't affect my results any, so I just don't spend the cycles or code space handling that case.
Great tutorial. The few times I tried to understand CORDIC I got lost pretty quickly. But I followed this all the way through. It makes complete sense.
A few typos:
then it must have been 0 and 45. If it remains positive then it must have been 45 and 90.
s/been/been between/g
The only side effect is that the hypotenuse does not keep its scale
s/it's/its/
Xnew=250+12=362
s/250/350/
On the following pages are two program that show how to use the CORDIC method.
Thank you. I have been told many times to use CORDIC, though did not understand CORDIC, (I had always used succive approximation in a way that turns out to be CORDIC). Thank you this helps my understanding so much.
John,
The 0.607 cordic gain is only for the HYP value. The angle should be the correct value.
When I get a chance I'll run the numbers and see what I get.
P.S. I just realized that the diagram on the first page is showing the angle measured from the right side. Normally it is measured from the left side, so you would get (90 - 53) = 37 degrees.
Did you try literally x := 3 and y := 4 in Bean's program from the pdf? If so that won't work well, because the program calls for units of 1/256, so the whole numbers 3 and 4 should be scaled up to x := 3*256 and y := 4*256.
I tried 3 and 4 without the *256, and it came out at 57.558 degrees, which is different from the value you reported and also different from the nearly correct value of 53.152 degrees that I come up with when x := 3*256 and y := 4*256.
It is true that the small values 3 and 4 by themselves should also come up with the same angle, however, it is necessary to modify the CORDIC program, an adaptive wrapper to scale small values up for computation and then back down, to avoid numerical errors.
Thanks for the prompt reply. I didn't scale down anything, and I had just now checked the older post about the Cordic (dated 2006), and it seems that you mentioned something about "method not usable in small numbers".
I'll scale the numbers as you said and try it on Matlab. Right now all I did on the Cordic is pencil-and-paper so it'll be a bit slow.
On top of that, I'll be writing the routines in small Atmega and PIC microcontrollers if it's successful.
This document demonstrates my long held belief that there are many brilliant but ultimately simple concepts in mathematics that almost anyone could understand if they could be presented in such a way as to avoid the blindness and confusion brought on by the symbols of mathematics itself.
Heater's comments lodged in my brain, back-in-the-day. So, today, when I eventually figured out what cyclic prefixing means in the context of OFDM design, Heater's remarks were the first thing that popped into my head. It amazes me how simple and straightforward concepts can be couched in such marvelously obfuscatory language...under the guise of explaining them!
BTW, it seems to me that Bean's CORDIC for Dummies thread has brought quite a few individuals to the Parallax forum for the first time, helping both Parallax and CORDIC enquirers. Can't beat that!
Comments
BTW, here are some other CORDIC threads:
http://forums.parallax.com/showthread.php?t=88799
and
http://forums.parallax.com/showthread.php?p=642142
The former has my attempts at understanding with some code the second is about my cordic engine which was some code designed to do pretty much all the mathematic operations using cordic. There is some code posted but I am not sure I posted or even finished the object.
Graham
Thank you once again Bean, You go dude!
http://www.amazon.com/Embedded-Systems-Building-Blocks-Second/dp/0879306041/sr=1-1/qid=1172159470/ref=sr_1_1/103-6846089-8685436?ie=UTF8&s=books
Please download it again from the first post to see the new version.
I still need to do a spin program to compute Sin/Cos but that shouldn't be too hard.
Bean
The improved document is great, thanks! Glad you added the SIN/COS stuff.
However, I noticed in your code example, you use the arithmetic shift right operator (~>) this doesn't work fully correctly for negative numbers. It won't shift a negative number down to 0. In cases where you want it to shift all the way down to 0, it'll end up with a -1.
In my example code posted above I showed a way to get around that. It also has my attempt at explaining the issue and the work around in the comments.
Roy
You can get it from the first post in this thread.
Enjoy,
Bean
Any response to the issue I brought up above about the ~> operator?
Roy
Jonathan
A few typos:
s/been/been between/g
s/it's/its/
s/250/350/
s/program/programs/
s/two/four/
Bean
YES, I didn't see the "above", but one should ALWAY use ~> if the numbers are not explicitely positive, what again should never be the case ,-)
I replaced all my >> by ~> if I not intend to clear the MSB.
A good idea to point to ~>, it just creates a savety margin
Sorry for bumping up the post, but I'm a bit confused about the algorithm.
I tested the algorithm with the x = 3 and y = 4, and it should give 53.13 degrees.
However, it's 43.695. Eventually I have to multiply it by 0.607 (cordic gain) and then multiply it by two again to get back the approximation.
What could I have been missing?
The 0.607 cordic gain is only for the HYP value. The angle should be the correct value.
When I get a chance I'll run the numbers and see what I get.
P.S. I just realized that the diagram on the first page is showing the angle measured from the right side. Normally it is measured from the left side, so you would get (90 - 53) = 37 degrees.
Bean
Did you try literally x := 3 and y := 4 in Bean's program from the pdf? If so that won't work well, because the program calls for units of 1/256, so the whole numbers 3 and 4 should be scaled up to x := 3*256 and y := 4*256.
I tried 3 and 4 without the *256, and it came out at 57.558 degrees, which is different from the value you reported and also different from the nearly correct value of 53.152 degrees that I come up with when x := 3*256 and y := 4*256.
It is true that the small values 3 and 4 by themselves should also come up with the same angle, however, it is necessary to modify the CORDIC program, an adaptive wrapper to scale small values up for computation and then back down, to avoid numerical errors.
Thanks for the prompt reply. I didn't scale down anything, and I had just now checked the older post about the Cordic (dated 2006), and it seems that you mentioned something about "method not usable in small numbers".
I'll scale the numbers as you said and try it on Matlab. Right now all I did on the Cordic is pencil-and-paper so it'll be a bit slow.
On top of that, I'll be writing the routines in small Atmega and PIC microcontrollers if it's successful.
Heater's comments lodged in my brain, back-in-the-day. So, today, when I eventually figured out what cyclic prefixing means in the context of OFDM design, Heater's remarks were the first thing that popped into my head. It amazes me how simple and straightforward concepts can be couched in such marvelously obfuscatory language...under the guise of explaining them!
BTW, it seems to me that Bean's CORDIC for Dummies thread has brought quite a few individuals to the Parallax forum for the first time, helping both Parallax and CORDIC enquirers. Can't beat that!