I'm totally a beginner in Trigonometry so my question may seem so trivial for many of you.
If my understanding is correct, based on the trigonometry a degree is defined by dividing the circumference of a circle into 360 equals parts so that each of those parts is called a degree. Now imagine that you open a circle and roll it on the table to form a simple straight segment (as if you actually drew a segment on a piece of paper using a ruler). You would then have a straight segment divided by 360 equal parts. What would be the distance between each degree ( = each division) in terms of millimetre on that segment? The reason that I ask this question is that I was looking to a protractor as you can see in the picture below:
The bottom of this protractor is an ordinary ruler and above of that we can see the measures of the degrees from 0 to 180. When I compare visually the measures on the ruler on the bottom with the degrees measures on the top of the protractor, it seems that they are the same and each degree has a distance of 1 millimetre from the next or previous degree. Is this true? Sorry if the question seems somewhat trivial for many of you but I'm completely a beginner in the field and I just try to understand how these units were actually defined.
The circumference of a circle is pi * the diameter, where pi is about 3.14159.
The diameter of your protractor looks to be about 120mm, so the circumference would be about 377 mm. Dividing by 360, each degree would be 1.05 mm -- pretty close.
That's so close that I wouldn't be surprised at all if the diameter of your protractor was actually designed to be 114.6mm, just to space the degree marks out by exactly 1mm.
here is what I want to do (preferably with Matlab):
Basically I have several traces of cars driving on an intersection. Each one is noisy, so I want to take the mean over all measurements to get a better approximation of the real route. In other words, I am looking for a way to approximate the Curve, which has the smallest distence to all of the meassured traces (in a least-square sense).
At the first glance, this is quite similar what can be achieved with spap2 of the CurveFitting Toolbox (good example in section Least-Squares Approximation here).
But this algorithm has some major drawback: It assumes a function (with exactly one y(x) for every x), but what I want is a curve in 2d (which may have several y(x) for one x). This leads to problems when cars turn right or left with more then 90 degrees.
Futhermore it takes the vertical offsets and not the perpendicular offsets (according to the definition on wolfram).
Has anybody an idea how to solve this problem? I thought of using a B-Spline and change the number of knots and the degree until I reached a certain fitting quality, but I can't find a way to solve this problem analytically or with the functions provided by the CurveFitting Toolbox. Is there a way to solve this without numerical optimization?
mbeckish is right. In order to get sufficient flexibility in the curve shape, you must use a parametric curve representation (x(t), y(t)) instead of an explicit representation y(x). See Parametric equation.
Given n successive points on the curve, assign them their true time if you know it or just integers 0..n-1 if you don't. Then call spap2 twice with vectors T, X and T, Y instead of X, Y. Now for arbitrary t you get a point (x, y) on the curve.
This won't give you a true least squares solution, but should be good enough for your needs.
What kind of algorithms would generate random "goo balls" like those in World of Goo. I'm using Proccesing, but any generic algorithm would do.
I guess it boils down to how to "randomly" make balls that are kind of round, but not perfectly round, and still looking realistic?
Thanks in advance!
The thing that makes objects realistic in World of Goo is not their shape, but the fact that the behavior of objects is a (more or less) realistic simulation of 2D physics, especially
bending, stretching, compressing (elastic deformation)
breaking due to stress
and all of the above with proper simulation of dynamics, with no perceivable shortcuts
So, try to make the behavior of your objects realistic and that will make them look (feel) realistic.
Not sure if this is what you're looking for since I can't look at that site from work. :)
A circle is just a special case of an ellipse, where the major and minor axes are equal. A squished ball shape is an ellipse where one of the axes is longer than the other. You can generate different lengths for the axes and rotate the ellipse around to get these kinds of irregular shapes.
Maybe Metaballs (wiki) are something to start from.. but I'm not sure.
Otherwise I would suggest a particle approach in which a ball is composed by many particles that stick together, giving an irregularity (mind that this needs a minimal physical engine to handle the spring body that keeps all particles together).
As Unreason said, World of Goo is not so much about shape, but physics simulation.
But an easy way to create ball-like irregular shapes could be to start with n vertices (points) V_1, V_2 ... V_n on a circle and apply some random deformation to it. There are many ways to do that, going from simply moving around some single vertices to complex physical simulations.
Some ideas:
1) Chose a random vertex V_i, chose a random vector T, apply that vector as a translation (movement) to V_i, apply T to all other vertices V_j, too, but scaled down depending on the "distance" from V_i (where distance could be the absolute differenece between j and i, or the actual geometric distance of V_j to V_i). For the scaling factor you could use any function f that is 1 for f(0) and decreasing for increasing distances (basically a radial basis function).
for each V_j
V_j = scalingFactor(distance(V_i, V_j)) * translationVector + V_j
2) You move V_i as in 1, but now you simulate springlike connections between all neigbouring vertices and iteratively move all vertices based on the forces created by stretched springs.
3) For more round shapes you can do 1) or 2) on the control points of a B-spline curve.
Beware of self-intersections when you move vertices too much.
Just some rough ideas, not tested...
Is there any use of Sin(720)or Cos(1440) (angles in degrees)?
Whether in computer programming or in any other situation?
In general, is there any use of Sin/Cosine/Tan of any angle
greater than 360?
In Physics we do use dot products and cross products
a lot, but even they require angles less than 180 degrees
always.
Hi All,
I know how to compute them....
I want to know, if they are ever useful????
When will I ever encounter a situation, when
I need to compute Sin(440) for example???
Both in math and programming:
Sin(x) = Sin(x % 360)
As another answer pointed out, angles greater than 360 represent one or more full rotations over a circle plus the modulo part. This could have a physical meaning in some circumstances.
Also, when doing trigonometric calculations, you should take this fact into consideration. For example:
sin(a)*cos(a) = (1/2)*sin(2a)
For a>180 you will get the sin of an angle greater than 360.
By the way, have a look here.
I have seen such things come up when doing angle arithmetic:
float angleOne = 150;
float angleTwo = 250;
//...
float result = Sin(angleOne + angleTwo); // Sin(400)
float result = Sin(angleOne - angleTwo); // Sin(-100)
In this (contrived) example, it seems obvious, but when you are computing an angle based on arbitrary rotations of several objects, you can't always know what kind of numbers you would be getting. Imagine calculating the poisition of the player in a 3D game while he is standing on top of a spinning platform, for example.
Any time you're dealing with a user interaction technique, it's entirely possible that they'll push you past 0 degrees or 360 degrees. Imagine that you're making a game with a gun turrent. It's currently pointed at 359 degrees and the user yanks the joystick to the right: now it's pointed at 361 degrees. If you implement the angular representation wrong, all of a sudden, the gun with rapidly traverse nearly 360 degrees to the left.
I predict that the users will be ... disappointed with that bug.
There are all sorts of issues that come up with Euler angle representations of the frame of reference that are important in games, simulations and real device control. Gimbal lock is a serious problem in actual rotating device control (it was a problem with camera pan / tilt devices in my life). The "rapid rotation" bug was a very nasty issue in a small boat autopilot system once upon a time - imagine wrapping a steel cable very tightly around the wheel house (i.e., you don't want to be standing there).
There have been times where the normal math means you end up "traversing the circle" one or more times, and if you keep the math simple your angles might be greater than 360. Personally I like to normalize the angles to be 0 to 360 or -180 to 180 after such operations, but it's doesn't really matter much.
Sometimes the greater number might really represent something. To take a trivial example, imagine instructions to open a classic dial combination safe. You need to spin the dial around a couple of times, so the instructions could be:
turn(800); // Twice around plus another 20 degrees
turn(-500); // Once around the other direction plus 140 degrees
turn(40); // Dial in the last digit
In that context, taking the sin or cos would tell you something about the ultimate position of the dial, but you would lose the information about how many turns were involved.
One rotation around a circle is 360 degrees or 2pi radians.
Trigonometric functions such as sine and cosine will "wrap around" when they reach 360 degrees and act the same way as being at 0 degrees. Basically, the following occurs:
angle_in_unit_circle = angle mod 360
Also, some trigonometric functions such as tangent are not defined at certain angles, such as 90 and 270 degrees, where tangent of an angle will return a positive or negative infinity.
This "wrapping" around can be seen by representing the sine, cosine, tangent functions using an right triangle inscribed in an unit circle, and this behavior makes those functions periodic because they will repeat their patterns over and over again.
Wikipedia has an extensive article on Trigonometric functions, so that might be worth taking a look at.
Usage
In terms of use, I can't quite think of a good example off the top of my head, except, maybe perhaps to represent a location of a particle at a certain time in a polar coordinate system, where the angle θ is dependent on time t:
r(θ(t)) = t where θ(t) = t
for values of t from 0 to 720, which could then be represented in a Cartesian coordinate system as:
x(t) = r sin(θ(t)) == t sin(t)
y(t) = r cos(θ(t)) == t cos(t)
The particle will be moving in a spiral type movement, dependent on the time t. In this case, the sine and cosine of angles beyond 360 will be calculated.
(And my math is rusty, so if there are any errors in the equations above, please let me know!)
On a sine curve, Sin(720) == Sin(0) (etc), so I'd expect any decent implementations of those functions to handle degrees "greater than" 360. There's any number of reasons for arriving at an angle greater than 360 or less than 0.
Angles outside the range of "principal angles" [-180,180) are essentially aliases of each other (modulo 360 degrees) and have no physical distinction.
From a mathematical/engineering sense, if you have a process where the # of rotations is important and must be kept track of (e.g. a motor that is spinning back and forth), then 0 degrees and 720 degrees are not the same. Sine and cosine are just periodic functions so they have the same value every 360 degrees. If you have a particle undergoing uniform circular motion where x(t) = A cos (ωt + φ) and y(t) = A sin (ωt + φ), then the phase angle θ = (ωt + φ) is going to be whatever it is, whether 0 or 720 degrees or 82144.33 degrees or whatever.
So the functions cos(θ) and sin(θ) just get used to calculate the x and y coordinates, no matter what the value of θ is. It's not like you have a choice in the matter, if θ is 82144.33 degrees then you're going to want to calculate the sine and cosine of that angle.
I play a PC game called Garry's Mod, and there are moments in the game where, when programming, I want a simple solution to keep an object constantly moving in a constant circle. To do this I use the sine and cosine of a forever increasing timer, measuring the amount of time since the game launched.
The sine of T (time) is equal to the orbit paths X value, while the cosine of T is equal to the orbit paths Y value(X and Y being on a 3 dimensional coordinate plane with Z not being used at the moment.)
Example:
T=1000 ticks
X=sin(T)
Y=cos(T)
So X is 0.8268795405320025 during that moment in time and Y is 0.15466840618074712.
Now let's say the amount of time grows to 1500. X would be -0.9939019569066535 and Y = -0.11026740251372914.
In a nutshell, it would constantly fluctuate from 1 to -1, leaving me the opportunity to multiply that value by say 100, and making the coordinate plane local to my characters position, then I can tell the programmed expression to move an object based on those coordinates and it would move in a constant circular path around me.
Tada. Who says you can't learn from video games?
Because sin(x) = sin(x mod 360°) and cos(x) = cos(x mod 360°) you can use every value in calculation, but you could also normalize to the range [0°,360°) or any other range of 360°. It just depends on the usage if large angles have a well defined meaning or not.
Processors will likley normalize the calculation to just a range of 90° or even less, and derive all other values from this small range.
When will arguments greater than 360° occur?
They naturaly occur in simulations of periodic time or space dependent functions.
Your question does not make much sense seeing as you seem to know the difference here:
No - you will never have to "compute" Sin(720), anymore than you will have a need to "compute" Sin(0). You need to look at the definition of the Sinus function to fully understand what goes on under the covers - and when that is understood it makes total sense for anyone as to why Sin(0) = Sin(720) - there's nothing magical going on, there's (logically) no Angle = FullAngle % 360 going on, it's all in the definition of what the function is supposed to do.
See wikipedia
#dta, I think folks are a little confused. You ask if it's ever "useful." I'd say "It doesn't matter, because you just shift the angle to the proper range when performing the calculation." There are certainly cases where you need to know how far from 0 degrees an object has rotated, accounting for multiple rotations. But aside from those cases, it's more convenient to interpret angles in the normal 0-360 range. Most people build up an intuitive feel for which direction corresponds to angles in that normal range. What direction does 170,234 degrees point? The same as 314 degrees.
As #Chris Arguin and others said, whether sin of an angle greater than 360° (or for that matter less than -360°) is useful to you depends on whether you need the information about rotations (or fractions thereof) that is represented by the difference between angle and angle%360°.
Also, since you get the same answer, you'll save a little processing time if you call sin(angle) instead of sin(angle%360), especially if you are doing many computations in a loop.
OTOH, #Scottie T makes a good point that if it is important for someone to know where around a circle your angle points, people can generally intuit position of an angle with an absolute value of 360 or less easier than they can for larger angles.
There are many circumstances where angles outside of [0,360] are needed. I like the idea of a combination lock. Here one will often see both positive and negative angles outside of the simple [0,360] degree range.
Multiple angle formulas are often important in mathematics. Trig functions are used in places other than just triangles. They appear in a variety of places, Fourier series for example, or image compression schemes, or the solution of differential equations. Computationally, it is true that you can always use mod to reduce the range for a trig function to the default. But it is rarely true that angles will always be provided in that nominal range.
There definitely can be times when you might end up with an angle measure > 360 degrees because of some kind of calculation...but it would be identical to an infinite number of other angle measures, exactly one of which will be between 0 and 360. However, if you are coding a function, you should be able to handle this calculation yourself...not rely on the user to do the mod for you.
ie While it is true that sin(370) == sin(10), and the user could do this translation themselves, they may not want to for one reason or another (see the "bolt" example in the comments for the top rated answer), and so the function should be able to handle any value.
Angles higher than 360 degrees are also used e.g. to describe snowboard tricks:
http://en.wikipedia.org/wiki/List_of_snowboard_tricks#Spins
So you see, there are various real world example where you use higher angles to describe the rotation of an object.
Given two 3D vectors A and B, I need to derive a rotation matrix which rotates from A to B.
This is what I came up with:
Derive cosine from acos(A . B)
Derive sine from asin(|A x B| / (|A| * |B|))
Use A x B as axis of rotation
Use matrix given near the bottom of this page (axis angle)
This works fine except for rotations of 0° (which I ignore) and 180° (which I treat as a special case). Is there a more graceful way to do this using the Direct3D library? I am looking for a Direct3D specific answer.
Edit: Removed acos and asin (see Hugh Allen's post)
No, you're pretty much doing it the best way possible. I don't think there is a built-in DirectX function that does what you want. For step 4, you can use D3DXMatrixRotationAxis(). Just be careful about the edge cases, such as when |A| or |B| is zero, or when the angle is 0° or 180°.
It's probably more of a typo than a thinko, but acos(A.B) is the angle, not its cosine. Similarly for point 2.
You can calculate the sin from the cos using sin^2 + cos^2 = 1. That is, sin = sqrt(1-cos*cos). This would be cheaper than the vector expression you are using, and also eliminate the special cases for 0/180 degrees.
You might look at the following article from siggraph link text
Maybe you can use D3DXMatrixLookAtLH ?