Topic awaiting preservation: help me think like a computer does (Page 1 of 1)

I didn't know where else to post this, so figured this was the closest forum...

My question is ActionScript code, but it's real close to JavaScript, so maybe one of you has a clue.

The formula to convert degrees to radians is: degrees times PI, divided by 180. In my mind, that would be coded as follows:

degreesToRadians = function(angle) {

return (angle * PI) / 180;

}

I have a ActionScript book by Robert Penner who codes it like this:

degreesToRadians = function(angle){

return angle * (Math.PI / 180);

}

I thought I had caught a typo, because I always thought expressions inside parens were evaluated first, but Colin Moock has a formula in his book that is:

degreesToRadians = function(angle) {

return (angle/180) * Math.PI;

}

What's going on, I ask myself? I put all three in a movie, and all three return the same value. For instance, if I set "angle" as 180, the following three functions ALL return 3.14159265358979.

Math.degreesToRadiansPenner = function (angle){

	return angle*(Math.PI/180);

};



Math.degreesToRadiansMoock = function(angle){

	return (angle/180)*Math.PI;

};



Math.degreesToRadiansSteve = function(angle){

	return (angle*Math.PI)/180;

};

Penner makes an explanation I find incomprehensible - Flash compiles the ActionScript into bytecode, and replaces numerical values for constants whenever it can. Okay. Putting parenthesis around (Math.PI/180) causes the compiler to evaluate the expression to a number, eliminating the need for division at runtime, improving performance. Fine. But ...

How can angle * (Math.PI / 180) = (angle / 180) * Math.PI = (angle * math.PI) / 180???

Um maybe I'm missing something but why wouldn't it work? I don't remember the words for it but

a*b/c as far as I know will always equal the same thing no matter the order of the arguments, operators or parens.





.:[ Never resist a perfect moment ]:.

okay. Clearly I'm being dense. Wouldn't (degrees * PI) / 180 mean you multiply inside the parens before dividing by 180? So how can that equal the same thing as, say, dividing PI by 180 and THEN multiplying by degrees?

I guess it doesn't really matter, I'm just ...

Multiplication is commutative. In other words, order doesn't matter.

Addition is also commutative, and this is easier to understand. We all know that 1 + 2 + 3 is the same as 1 + 3 + 2 and 3 + 1 + 2, etc. Order isn't important. If you bring in parenthesis, it doesn't make a difference ( (1+2)+3 is equivalent to 1+(2+3).)

Now, division can be thought of multiplication by a reciprocal. In other words, this:

angle / 180 * PI

is equivalent to this:

angle * (1/180) * PI

And since multiplication is commutative, you can change the order in any way you want:

angle * PI * (1/180)

and then undo the reciprocal and bring the division back in:

angle * PI / 180

and it still has the same value.

Note that you can't just *randomly* add parenthesis when you're mixing two types of operators (* and / in this case). If you did this:

angle / (180 * PI)

it would *not* be equivalent, because that evaluates to

angle / 180 / PI

Does that make sense?

"Does that make sense?"
Thank you Slime. No it doesn't, but thanks for making the effort. This clearly is NOT something having to do with how computers evaluate expressions, but rather something I should have retained from basic math classes which I, clearly, did not. It's a little counter-intuitive for me at the moment, but I'll just have to live with that!

So - getting back to coding - is there any practical advantage to one or the other of the forms presented? Is Penner actually squeezing any more efficiency by enclosing the PI/180 inside the parenthesis? Or would all three forms evaluate in about the same degree of effort for a computer (in which case I'll use the form where the parenthesis make sense to me)?

Steve:

Try thinking about it this way: (2*3)/4 = 2*(3/4) = 2*3/4 = 3*(2/4) ...

quote:

---

(2 * 3)
-------
4

---

These are all the same value. Now you can place variables in the equation like (x*y)/z and see that they all give the same answer.

This is just another way of saying what Slime said: Multiplication is commutative: X * Y = y * X.




-- not necessarily stoned... just beautiful.

Perhaps if you take the same formula with simpler numbers it will make more sense -

10 x 2 / 5 = 4 (10 x 2 = 20. 20 / 5 = 4)

10 / 5 x 2 = 4 (10 / 5 = 2. 2 x 2 = 4)

The order makes no difference becasue either way you're dealing with the same set of numbers. If you were to throw an addition or a subtraction in with the multiplication or division, then you have to have strict ordering.

Just as

10 + 2 - 5 = 7
10 - 5 + 2 = 7

No matter how you slice it, you still have the same number of positive and negative, so regardless of the order, you'll end up with the same sum.

Thanks for all the input. It's gradually making sense (multiplying by reciprocal helped, as did swapping in smaller simpler numbers).

So why do Moock and Penner use parenthesis at all if it could be just as easily stated:
angle * Math.PI / 180;
? Is there in fact some code optimization gained by putting PI and some operation in parenthesis?

I don't actually know, but I would guess just force of habit.
You get used to putting parentheses in your formulas, so they sneak in even when not needed.

When most people learn the conversion in school, it's said "multiply by the following constant: PI/180". So, they were probably thinking like that, and used angle * (PI/180) because it holds the constant expression together.

Personally, I would think about it like (angle/180) * PI, since it seems to make more sense to divide by 180, in order to get a number where 0 represents no angle and 1 represents a flat angle (and .5 represents a 90 degree angle), and then multiply by PI, magnifying the 1 to PI so that now PI represents a flat angle. But that's just me.

It's all about how you think about the problem:

Penner's solution kinda makes sense because (Math.PI/180) is really a constant. This is the number of 'radians per degree'. Thus multiplying this times any angle measured in degrees yields radians.

I think Mock was thinking about "What percentage of 180 degrees is this angle? Then multiply by the equivalent number of radians..."
Sort of convoluted but could make sense.

And your approach is the straight forward "let-me-calculate-the-numerator-before-I-deal-with-the-denominator". This is a good approach to take as you don't then get it trouble when the calculation of your numerator involves operations other than multiplication (like addition).

Thanks one and all. I've truly learned something I should have known all along.

Slime: "But that's just me." - No, it's you and Colin Moock, two individuals whose command of things code and math I consider indisputable!

Slime & MajorFracas: your comment about PI/180 being the classic "textbook" constant I'm sure explains Penner's approach. So there is much to be said for that.

And MajorFracas - heh - thanks for being kind about my "safe" approach!