Skip to main content
GameDev.net gamedev.net
🔒 Locked

Bizare Vector math Problem!

Started by Jouei Jan 19, 2007 at 2:12 PM 8 replies 1.1k views
Original Post
Jouei
Jouei
Ok so ill give you the lay down of the problem and then any other information that may be releavint. So i have writne a basic command line applcation just to test some code for movment based on angle. The real problem sees that its ouputs are well irradict. I will put the code below its not very long however i would like to note that i have not inverted the y axis. //Code int main () { int X = 0; int Y = 0; int Velocity =5; float Angle; cin >>Angle; float NewX = X + Velocity*cos(angle); float NewY = Y + Velocity*sin(angle); cout <<"The new X postion is: "; cout <<NewY; cout <<"\nThe new Y postion is:"; cout <<NewX; getch(); return 0; } //Code Just on a side note im compiling on Visual C++ Express i do have such heard files as math.h, conio.h,iostream,and studio.h I did try before had to search for a post that was simmlar to this or that may have identifyed the problem however nothing seems to really work as iv been on this question almost a week now. So i would like to applogize to anyone a head of time for A) poor spelling. B) if its a rather stupid mistake !
jouley
jouley
The problem is likely that the sin and cos functions expect their parameters to be expressed in terms of radians. So, multiply your angle (after entering it as degrees) by PI / 180.0 (roughly 0.017453292519943295769236907684886) to convert from degrees to radians:
float Angle;cin >>Angle;Angle *= 0.01745329f;  // that's plenty// ... use angle


Did that do the trick?
-jouley
baumep
baumep
Maybe your problem is that these functions work with radians instead of degrees (e.g. cos).
Try converting degrees to radians and vice versa.

[Edit: spelling, too late and nice coincidence with your nicks :-)]
baumep
Jouei
Jouei
WOW dont i feel abit like a tard -.- .......

ok well i thank you a thosand times ...
And let this be a lesson to anyone in the future... Including me!

Now that i notice the nicks yes LOL thanks for pointing that out i need abit of a luagh !
TheAdmiral
TheAdmiral
Quote:
Original post by jouley
PI / 180.0 (roughly 0.017453292519943295769236907684886)

Roughly? [wink]
Ring3 Circus - Diary of a programmer, journal of a hacker.
Brother Bob
Brother Bob
Quote:
Original post by TheAdmiral
Quote:
Original post by jouley
PI / 180.0 (roughly 0.017453292519943295769236907684886)

Roughly? [wink]

Given that the exact answer contains an infinite number of decimals, one could say it's a rough approximation since he only provided a tiny, tiny fraction of them. But the relative error in the answer on the other hand...
pTymN
pTymN
Kinda silly to use more digits than long doubles provide...
 
taby
taby
Quote:
Original post by pTymN
Kinda silly to use more digits than long doubles provide...


Agreed.

static const float_type coefficient = PI/180.0; // only calculated once, precision based on type
CTar
CTar
Quote:
Original post by pTymN
Kinda silly to use more digits than long doubles provide...


How many digits does a double provide? Precision isn't measured in decimal digits, and even if it was, it isn't specified in the standard how many digits a long double provides. The usual double (double precision defined by the IEEE standard) can hold 2-1022 which is over 300 digits (approximately 2.225 *10-308).

Of course the real solution is to calculate it (PI/180).
Raghar
Raghar
We are living in 64 bit computing. Thus you have data type float, and double. That's it, live with it.

(Of course there is also half, and a high precision libraries, however they don't run on standard CPU directly.)

To cite AMD. Legacy floating point has been DEPRECATED. (Not to mention that legacy floating point spelled disaster with portability, and would cause significant problem with converting legacy code into 64 one.)

Now if we would like to be assine, we will note that multiplication by inversion isn't the same as division. (computers have limited precission, and accuracy)

What matters for accuracy is amount of bits in mantisa, and amount of guard bits. So amount of decimal places would be 52*log(2)/log(10) round down. It's roughly 15 decimal places, not 300. 52 * 3 / 10

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.