View Single Post
  #1   Spotlight this post!  
Unread 27-04-2004, 21:51
mtrawls's Avatar
mtrawls mtrawls is offline
I am JVN! (John von Neumann)
#0122 (NASA Knights)
Team Role: Programmer
 
Join Date: Mar 2003
Location: Hampton, VA
Posts: 295
mtrawls is a splendid one to beholdmtrawls is a splendid one to beholdmtrawls is a splendid one to beholdmtrawls is a splendid one to beholdmtrawls is a splendid one to beholdmtrawls is a splendid one to beholdmtrawls is a splendid one to behold
Send a message via AIM to mtrawls
Re: White Paper Discuss: 296's CORDIC Math Library

We didn't use trig in our final implementation ... but in testing we did consider it, and also decided on the CORDIC algorithm. There is an added advantage of CORDIC that your library currently doesn't utilize -- it can compute both the sin and cosine at the same time (which you do, but then you throw one of them away). For our trig needs, anyway, we needed the sin and cos of the same angles.

Implementing this in a math library (admittedly more general than our custom implementation), would be interesting conceptually. Maybe create a structure called angle.
Code:
struct angle {
  short long angle;
  short long sin, cos;
  ...
};
...
short long Sin (angle ang) {
  ...
  ang.cos = blah;
  ang.sin = more blah;
  return ang.sin;
}
This function in addition to the normal sin function (i.e., that doesn't take a struct as an argument). Maybe this is too much for something that is too specific, whereas this is a general library. But then again, maybe other teams had the same need as we did, and could stand to benefit from not doing extraneous processing. Note that all this is off the top of my head without thinking about it as often as I ought to (which for some reason is why I end up with bugs in my code ... go figure). I can imagine other implementations, equally or more valid than this -- this suggestion is more conceptual than offering actual code implementation.
Reply With Quote