Fast Math and Low Precision Trignometry

I think I finally got working versions of my two containers done, array and list. Been playing with them for a while and finally got them to compile and made simple runs with them. I'll have to continue to work on the stack, queue, and maybe set containers. May build a hash table container as well, based on some of the things from the 3DGEA book.

The next step up is to start building the math modules. There is definitely a need fast math processing especially in 3D intensive applications. Probably the core has to be calculating trig values like sin and cos and stuff like that. The book presents some examples of lower precision expansions of these trig functions based on Taylor Series, but I think we can abuse the system a little more, especially when the precision we seek is below 0.001.

Based on the sample given in the book, we can easily achieve errors of less than 10^-6 with reduced versions of the sin and cos expansion, but I believe that we can reduce the process to about 3 multiplication and 4 addition operations, if not less, by generating a look up table. The nice thing about templates is that they are generated during compile time into actual classes. So, it is possible to generate a look up table of sin or cos values during compile time with the use of templates. So, we can generate a lookup table with values of more than 10^-9 in accuracy. The look up table will be based on degrees, not radians, but the class will have a radian to degree conversion, which is where 1 multiplication step is. sin and cos values are nice because they are continuous. So, we can start by generating a lookup table with 360 entries. So, what if an angle is not an integer? We can simply do an linear interpolation based on the 2 integer values its in between. This will take 1 multiplication, 2 subtraction, 1 addition, and 2 array entry accesses. All these can be done fairly easily and quicker than solving the taylor series. For sin and cos, the error is around 10^-4 to 10^-5, which is fairly reasonable. For most cases, that kind of precision is enough.

You can further reduce the look up table size in memory by exploiting symmetry in the values of cos and sin, which can at least half the memory requirement, which should be around 720B if using floating points and 1,440B if using doubles. So, the two look up tables will take up a max of 2,880B and should cover values for tan as well.

Of course, tests have to be performed to see if the speed up is worth the memory trade-off. I think i some cases its worth it. Implementation-wise, I think I'll use all three methods of calling the C/C++ math module, the lower precision fast math methods given in the book, which at least gives 4x speed up, and my look up table method. Depending on how things go though, the lookup table method may have to go. We'll see. :p