View Single Post
  #5   Spotlight this post!  
Unread 04-12-2006, 08:16
Bongle's Avatar
Bongle Bongle is offline
Registered User
FRC #2702 (REBotics)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2002
Location: Waterloo
Posts: 1,069
Bongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond repute
Send a message via MSN to Bongle
Re: Trig. Functions in EasyC

Quote:
Originally Posted by TubaMorg
I would like to suggest, without actually knowing your specific application, that you might want to utilize a lookup table. If it is a situation where you need to do the calculations many, many times, then a lookup table will save you computation time as trig functions do have some overhead. Precalculate your trig function for, say, 0-359 degrees and plug the values into an array (indexed 0-359 of course!). Then when needed you just index the array for the answer. If this is a navigation application 0-359 degrees should really be enough resolution, given the error inherent in the sensors. The only drawback is, of course, you have to use up memory to store the array of floats.
I always forget about lookup tables

I'm not sure how much code space the VEX controller has, but 360 floats in a table is 1440 bytes, which is quite a bit. Another idea in that vein would be to have a smaller table (45 entries) and just interpolate between them.
Code:
float GetSin(int degrees)
{
  int subDegrees = degrees & 7; // gets the last 3 bits
  int tableIndex = degrees / 8; // finds out the table entry we want
  return ((8-subDegrees)*table[tableIndex] + subDegrees*table[tableIndex+1])/8;
}
This function is a very simple linear interpolation. But it would allow you to have a much smaller table taking up much less memory. Another improvement would be to only have a table for between -PI/2 and PI/2, then using the same techniques I posted in my first post to get answers for PI/2 and beyond. This would again cut table size in half.
Reply With Quote