Angle Altitute Calculations

[Kitsune]

It has been many years since I really have used Geometry (20+)...does someone know a website which will refresh me enough to do some calculations for a game?

[Gil Hamilton]

What are you looking to do? Find the maximum height of a projectile with a given angle and velocity?

I can tell you how to do it yourself. It's actually not so bad.

Keep in mind that velocity is the derivative of position with respect to time. Also, note that the maximum height of a ballistic projectile occurs when the rate of vertical change in position (i.e. vertical velocity) is zero.

Pretty much take the derivative wrt time of the vertical position function (or alternatively take the integral wrt of gravity, same thing), set that equal to zero, solve for time, and plug it back into the position equation, then clean up.

The result will be:

y(max) = (v0*sin(theta))^2 / 2*g ;

where y(max) is the maximum height of the projectile, v0 is the exit velocity of the cannon, theta is the angle of the cannon, and g is the gravity of the system.

[Kitsune]

I feel a bit embarrassed,
I mean simply the sin/cosin relationship with everything.
I cannot remember it at all and I used to be good at it.
I have a dragon which is 500 feet away straight line and is 150 feet in the air. I am trying to figure out how far along the ground the dragon would be

[Terralthra]

Sine = opposite / hypotenuse
Cosine = adjacent / hypotenuse
Tangent = opposite / adjacent

The problem you posed is effectively:

150 (opposite) / 500 (hypotenuse) = .3
sin theta (viewing angle) = 0.3
theta = arcsin(0.3)
theta = 17.45 degrees.

distance / 500 = cos (17)
distance = .95 * 500
distance = 476.989

Just a quick double-check via Pythagoras' Theorem
sqrt( 476.989^2 + 150^2 ) = ?
sqrt( 227518.506121 + 22500 ) = 500.01

[Gil Hamilton]

You don't even need to mess with trig for that. That's a straight up Pythagorean Theorem App.

Assuming level ground, the straight distance is the hypotenuse and vertical height from the ground is one leg of a right triangle.

a^2 + b^2 = c^2

(150)^2 + b^2 = (500)^2
b = SQRT((500)^2 - (150)^2)
b = 476.969 ft

[Kitsune]

You don't even need to mess with trig for that. That's a straight up Pythagorean Theorem App.

Assuming level ground, the straight distance is the hypotenuse and vertical height from the ground is one leg of a right triangle.

a^2 + b^2 = c^2

(150)^2 + b^2 = (500)^2
b = SQRT((500)^2 - (150)^2)
b = 476.969 ft

Thanks, I will save the theorem for later use if I need to

[Terralthra]

You don't even need to mess with trig for that. That's a straight up Pythagorean Theorem App.

Assuming level ground, the straight distance is the hypotenuse and vertical height from the ground is one leg of a right triangle.

a^2 + b^2 = c^2

(150)^2 + b^2 = (500)^2
b = SQRT((500)^2 - (150)^2)
b = 476.969 ft

Assuming this is an engine calculation which would probably be done many times for many entities, the trigonometric method is in general, superior. It involves only multiplication operations, since the sin/cos operations can be done using a look-up table, for excellent speed. Square-roots of arbitrary floating point numbers, on the other hand...

[Gil Hamilton]

Assuming this is an engine calculation which would probably be done many times for many entities, the trigonometric method is in general, superior. It involves only multiplication operations, since the sin/cos operations can be done using a look-up table, for excellent speed. Square-roots of arbitrary floating point numbers, on the other hand...

I'm not a programmer, so you are probably right. I just know the most direct was to do it if I'M the one doing the calculation.

Of course, I was so unsophisticated that I did it on a pocket calculator and cooked up the above max height equation on a scrap of debris on my desk, which actually is the proper way to do physics, I understand.

[Kuroneko]

Assuming this is an engine calculation which would probably be done many times for many entities, the trigonometric method is in general, superior. It involves only multiplication operations, since the sin/cos operations can be done using a look-up table, for excellent speed. Square-roots of arbitrary floating point numbers, on the other hand...

Some of this probably depends on the architecture, but for the most part, it's simply not true. I haven't done any serious assembly programming since the Pentium was new, but I recall that square roots were about as expensive as division on a 486, and sin/cos were five or more times as much. I'm fairly certain that even on new processors, an inverse sine and a cosine would have a much higher latency than a single square root for a given precision. Plus, some architectures use a lookup table for sqrt anyway, followed by a Newton-Raphson iteration to increase precision.

(Still, this is mostly moot because that's very far from the application the OP is intending.)

[Gil Hamilton]

Some of this probably depends on the architecture, but for the most part, it's simply not true. I haven't done any serious assembly programming since the Pentium was new, but I recall that square roots were about as expensive as division on a 486, and sin/cos were five or more times as much. I'm fairly certain that even on new processors, an inverse sine and a cosine would have a much higher latency than a single square root for a given precision. Plus, some architectures use a lookup table for sqrt anyway, followed by a Newton-Raphson iteration to increase precision.

(Still, this is mostly moot because that's very far from the application the OP is intending.)

Well, I know from doing square roots by hand, the process is exactly as time consuming as doing long division. I can imagine an algorithm for calculating a square root is about as hard, but I may be misapplying human logic to computers.

[Terralthra]

Assuming this is an engine calculation which would probably be done many times for many entities, the trigonometric method is in general, superior. It involves only multiplication operations, since the sin/cos operations can be done using a look-up table, for excellent speed. Square-roots of arbitrary floating point numbers, on the other hand...

Some of this probably depends on the architecture, but for the most part, it's simply not true. I haven't done any serious assembly programming since the Pentium was new, but I recall that square roots were about as expensive as division on a 486, and sin/cos were five or more times as much. I'm fairly certain that even on new processors, an inverse sine and a cosine would have a much higher latency than a single square root for a given precision. Plus, some architectures use a lookup table for sqrt anyway, followed by a Newton-Raphson iteration to increase precision.

(Still, this is mostly moot because that's very far from the application the OP is intending.)

To the latter first, I did mention using a lookup table for the trig functions, because calculating them on the fly would be just as time-consuming.

As for the sqrt/long div thing, that's not been my experience from doing engine calcs in C/C++ over the past 10 years or so. I realize this is anecdotal evidence, so I guess until/unless someone else enters the debate with something other than an anecdote, we can agree to disagree?

[Gil Hamilton]

I'm not disagreeing with you. I just know that the way you do square roots on paper is actually very similar to the way you do long division and takes about as long, which sort of makes sense with what Kuroneko said that square rooting was similar to division in computer resources. Since I know very little about computer science, I'll defer to experience of course.

[Kuroneko]

To the latter first, I did mention using a lookup table for the trig functions, because calculating them on the fly would be just as time-consuming.

You misunderstand. My point is that using a tables for speeding up calculations can be done with pretty much any function, and in fact some processors already have built-in tables for the calculation of square roots. Hence, as an "all else being equal" comparison, tables are irrelevant: much of the the same techniques can be translated to apply to square roots. (In fact, it's much easier--a follow-up Newton-Raphson iteration easily doubles the precision, requiring much less computation if precision greater than that found in the table is required.)

As for the sqrt/long div thing, that's not been my experience from doing engine calcs in C/C++ over the past 10 years or so. I realize this is anecdotal evidence, so I guess until/unless someone else enters the debate with something other than an anecdote, we can agree to disagree?

It's more than an anecdote--I remember the general latency rankings of those instructions on the 486 because that's what I learned assembly on (well, sort of--most of the literature I've used was intended for 386 and 486, but I actually coded on the Pentium). Besides, this is something quite easy to look up again. Most of the data is taken from this page.

Code: Select all

Where applicable, single/double/exended precision variants are given.
Ranges marked with an asterisk are for "typical" arguments. Certain
arguments may be much faster, others slower. For example, on P1 fcos
actually ranges from as low as 18 to as high as 124 cycles and fpatan
from 17 to 173.
       486      P1        P2,PPro,P3  Core2   P4        AMD64
fdiv   73       19/33/39  18/32/38    5-37    23/38/43  11-25
fsqrt  83-87    70        69          6-69    43        27
fcos   257-354  60-100*   27-103      96*     200*      150-190
fpatan 200-273  112-134*  25-86       70*     187*      217

Well, it did turn out that on the 486, the fdiv and fsqrt are indeed close enough compared to the variability in the trig functions, but the factor should've been 3-4 instead of 5 for comparison with fcos. However, this minor failure of my memory aside, the general point stands: square roots are a lot faster than trigonometric functions on the 486, and curiously, this is even more true on the AMD 64-bit family. It may be said that for the intermediate architectures (and favorable arguments), the calculation of cosine is favorable compared to the square root. Taken by itself, that may be, but this doesn't translate to a favorable method for two reasons: the approach calls for two trig functions, and in fact a hardware implementation of the inverse sine would have to go through inverse tangent (as there is no fasin), and thus involve an extra square root an an extra division to go transform properly. So, at the hardware level, it's a choice between
(a) two multiplications, a sum, and a square root, or
(b) two divisions, two multiplications, a subtraction, a square root, an arctangent, and a cosine.
It's not even a contest. Additionally, the Pythagorean approach allows for at least some pipelining (on P+), and which will could make the second square almost free.