sin, cos, tan problems

[BigKevSexyMan]

I'm having some problems with Math.sin and co. Here's were my coding is so far.

@angle = 270
angle_to_rad = @angle * Math::PI / 180
print angle_to_rad
y_increase = Math.sin(angle_to_rad)
x_increase = Math.cos(angle_to_rad)
print x_increase.to_s + ", " + y_increase.to_s
print y_increase / x_increase

Now, I should be getting a divide by 0 error, but these are the results I get in the order of the prints.

4.71238898038469 -angle_to_rad
-1.83690953073357e-016, -1.0 -x_increase.to_s + ", " + y_increase.to_s
5.4439262427946150e+015 -y_increase / x_increase

x_increase is supposed to be a 0

This throws me WAY off here and I need to figure out what the problem is.

 

[arev]

the arguments shuold be in degrees, not in radians. unless you're trying to do something special :]
tell me what is it, and maybe I'll be able to help more.

 

[BigKevSexyMan]

Nope, it has to be in radians.

Math.cos(x)
Math.sin(x)
Math.tan(x)
Returns the value of the trigonometric functions of x in radians, in the range [-1, 1].

That's from the help file.

Basically, what I'm doing is I'm giving each event an angle to move by. In order to set up the slope for the formula.

 

[arev]

oh yeah, I forgot that :p
anyway, this may be due to a numer of digits after the coma.
you can try initializing the x and y increase as 0.0 first, and then instead of equaling the sin and cos to it - add them. like this:
x_increase = 0.0
x_increase += Math.cos(blablabla)
it's a bit unprofessional but it may help. you can also try it with the angle_to_rad.

p.s. are you trying to make a new movement engine, where the moving axes could be defined by a variable? :D

 

[BigKevSexyMan]

The problem isn't with the x_increase. The problem just affects it. I think the problem lies in Math::PI and/or angle_to_rad. I think it's rounding my numbers to short. Any idea how I can fix this?

 

[Exsharaen]

Math:I? Are you sure? I found Math::PI instead if you refer to PI constant (3.141592654...).

Your problem doesn't lie in angle_to_rad = @angle * Math::PI / 180 line. Technically, RGSS will round your division if all operand are integers. Since Math::PI always returns a floating-point, your angle_to_rad will always be in floating-point.

The main problem actually lies within these three trigonometric functions RGSS provides us: Math.sin(), Math.cos(), and Math.tan().

Although our teachers might have taught us that cos(270) or cos(90) is 0, some calculators doesn't agree with that. Very Scientific calculators might show -1.83690953073357e-016 instead, and it seems that RGSS uses this value. Although, since this will lead to problems when calculating, there was an agreement to simplify it to 0. That's why RGSS produces a value that is different from expected.

Spoiler: Mathematical explanation of this problem

I use degree for every trigonometric functions here to simplify the problem.

This is a little bit mathematic, but it's logical too. See, when cos(270) = -cos(90) = -1.83690953073357e-016 and sin(270) = -sin(90) = -1.0, you can expect what you will get when you do -1.0 / -1.83690953073357e-016: a very large number indeed.

Using another approach, your y_increase / x_increase is actually the same as tan(270), or furthermore is the same as tan(90) since 270 degrees lies in third quadrant (which positive value will be given for tangent). I was taught that tan(90) is undefined (since a division by a zero is not allowed), but later I know that it's infinite instead. If you remember drawing tangent graph, it will goes off the limit when you draw tan(90). Try this code to prove it:

p Math.tan(angle_to_rad)

You will get (maybe not exact) 5.4439262427946150e+015.

Hope this helps.

 

[arev]

I know it's not a problem with x_increase but I think this may help. as for the rounding the numbers - what accuracy do you need there? I'm guessing anything above noe digit after coma is rather useless, though I may be wrong ofcourse.

 

[Ceroscuro]

x_increase is so close to zero I'm not sure it matters. x_increase is -0.0000000000000000183690953073357. That's VERY close to zero.

 

[BigKevSexyMan]

Ok, I ran what the rgss was running, to the digit, through my calculator and it gives me what the rgss gives me. I think my problem lies in Math::PI. I tried doing my own pi with many more digits, but that gets rounded off, too.

x_increase is so close to zero I'm not sure it matters. x_increase is -0.0000000000000000183690953073357. That's VERY close to zero.

Yeah, but when you divide something by x_increase you get a huge number. Maybe what I could so is set an if statement that checks if a number is that low, and if it is round it off to 0, but there still may be innaccuracies with my other numbers that aren't 270 and 90 degrees.

I know it's not a problem with x_increase but I think this may help. as for the rounding the numbers - what accuracy do you need there? I'm guessing anything above noe digit after coma is rather useless, though I may be wrong ofcourse.

I need a high amount of accuracy. When x_increase ends up being 0, then I know I got enough.

 

[arev]

SOLVED! http://www.oaza.rut.pl/oaza2/images/smi ... st_h4h.gif[/img]
make it like this:

x_increase = Math.sqrt(1 - (Math.sin(angle_to_rad))*(Math.sin(angle_to_rad)))
y_increase = Math.sqrt(1 - (Math.cos(angle_to_rad))*(Math.cos(angle_to_rad)))

I've also made a small calculator (yeah, I know...):
http://www.calamity.cba.pl/files/rmxp/MATH.rar

p.s. note, that for angles = 45deg + k*90deg, x and y are different in the 14th place. it's that bloody rounding :]

edit: sorry, but it seems that the previous version of the calcukator was broken. it's fixed now, so if you'dl ike to test it - download it again

 

[BigKevSexyMan]

Well, that's pretty cool, but I've noticed a little something wrong with it. It's missing negative numbers, but it can fixed with a little knowledge of quadrants.

That's a ton, this is very useful.

 

[arev]

hell... how could I've this? ^_^
but it seems you'll handle this one so I'll leave it up to you