A brief study on Cosine Generators

Recently I have been studying rotations. I was particularly interested in the primitive mathematics involved in the conversion between Polar and Cartesian coordinate systems. Usually you are told to use the trig functions to do this. What was actually happening always seemed hidden in the implementation of the trig functions, so I took the time to implement a cosine generator based on a report a man by the name of Dr. William D. Bishop had come up with.

Although this is just a study of the implementation of just one of these functions, it has changed the way I think of trigonometry, and even mathematics.

Here is a cosine generator that Dr. Bishop says is faster than the traditional CORDIC algorithm. This algorithm was written for hardware implementation. This is purely for educational purposes and is rather useless – it is an order of magnitude slower than the AVM internal cosine function.

Actionscript benchmark implementation

function computeSeries(precision:int = 12):Array {
    var r:Array = [];
    for(var n:Number = -1;++n < precision ;){
        r[n] = Math.pow(-1, n)/factorial(2*n);
    }
    return r;
}
 
function factorial(i:Number):Number {
    if(i>1) return i*arguments.callee(i-1);
    return 1;
}
 
function cosFunc(a:Number):Number {
    var r:Number = 0;
    for(var n:Number = -1;++n < series.length ;){
        r += series[n]*Math.pow(a, 2*n);
    }
    return r;
}
 
var series:Array = computeSeries(12);
 
var startTime:Number = flash.utils.getTimer();
for(var i:int = -1;++i<1000000;){
    //Math.cos(Math.PI);
    cosFunc(Math.PI); //whoops wicked slow.
}
trace(getTimer()-startTime);

The Math
http://www.dgp.toronto.edu/~derek/cosine_report.pdf

Concrete knowledge
In this study, it is clear to me why and how sine/cosine are functions of radians. They are directly related to PI since a radian is the unit measure of angles to the limit of PI, and the result of sine/cosine can be thought of as a normalized axis coordinate. On the other hand, normalizing a scalar can get us the radian measure of an angle using the inverse trigonometric functions – arc sine/cosine etc. This isn’t anything I did not already know, but I am beginning to understand how systems like Trigonometry work with normal quantities.

Conclusion
The implementation of trigonometric functions has been a question mark in my head for quite some time. When I was studying trigonometry, I looked for how the functions were implemented. All I could find was how to use them or what they do and all of the annoying identities and proofs that it works. The implementation of trigonometric functions is never really talked about in mathematics. I have learned that other concepts in mathematics are able to describe Trigonometry in general terms. Viewing it in general terms has both helped me understand and properly place the system and the mechanics it is composed of.

Other thoughts
PI as they say keeps everything together in the universe – but in order to protect myself from narrow mindedness, I am trying to think of PI as a result of a certain geometric way of interpreting and measuring space. I haven’t done enough studying to be sure of this, but I plan to, and in the mean time, this will be my approach to higher maths. I am hoping it will help me avoid getting trapped in formulating useless analogies. If anyone has any guidance on this, please leave a comment :)

1 Responses to “A brief study on Cosine Generators”


  • Well I think it’s unfair to say it’s quicker than the CORDIC algorithm here’s why:

    1. Different computer hardware would respond differently to the code. If there was, for example, a trig coprocessor then surely using a function call that utilized that coprocessor would be quicker than calculating factorials.

    2. Also, Dr, Bishop’s algorithm might be quicker for certain applications such as calculating discrete sin or cosine but if you had an application like 3D graphics where you needed to rotate an object through space then the CORDIC might be much quicker still. This is because the CORDIC works by calculating in iterative steps. In the case of animation you want the iterative steps for visual smoothness. So if you don’t need to call a Sin or Cosine you simply iterate one (or more) steps.

    3. The basic CORDIC calculation is essentially of the form X’=X+deltaY thereby requiring four variables and four adds ( for each iterative step.

    4. Dr Bishop’s algorithm would probably be much more accurate for most applications since the size of the accuracy will improve as the size of iteration decreases. So it is slow and accurate or fast and potentially quite inaccurate. If you’re talking about smoothness of motion in a computer game (for example) then accuracy probably isn’t such a big deal but just a rendering artifact anyway.

Leave a Reply