Technically it doesn't, but the way the equation is laid out, it is sort of implied. 1/2A is technically A/2, but most people would read it as 1/(2A). When variables/numbers are clumped together without a multiplier symbol, it typically implies that you want them together. Another Example cos 3x most people see it as cos (3x) but rarely will anyone ever see it as 3cos x. It has nothing to do with whats outside of the parenthesis but rather it was typed out in a fashion of 2(9+3) over 2*(9+3). when typed out in the former, you are implying that you want the numbers together in the denominator. That is where the confusion is coming from is that implicit assumption people make.
oops mistake in example" cos 3x most people see it as cos (3x) but rarely will anyone ever see it as 3cos x. I meant cos 3x most people see it as cos (3x) but rarely will anyone ever see it as xcos 3.
When I first did the equation, I came up with 2. If you solve it strictly by basic math, its very simple to see how you get 288. Its when people try to rationalize algebraically they get the order of operations mixed up. Forget the numbers and turn it into an algebraic equation. X=48 Y=2 A=3 B=9 You would read it: x/y(a+b) Many people are reading it incorrectly as: x ------ y(a+b) the correct way to read it is: x (a+b) -- *-- y 1 Its not the simple math people are screwing up, its the algebra.
As said before, write the equation exactly as stated in Excel, SAS, SQL, C++ and what ever else math programing language that can take an algorithm, and let me know which one will return the value of two.
Hmmmm... Ok, let's actually examine this perhaps a little more than you did. Using your very same numbers: $50 in your account $3 debit $2 credit $5 credit First, you placed them in order: 50 -3 +2 +5 and came to a total of 54 You are correct. Then you asked: But what if I had started from the right side and did the 2+5 operation first? Would I still get the same result? Well, let's find out. You didn't mention where you would like the 50, so what the heck, let's just tack it on at the end. Doesn't matter, put it wherever you want. Let's begin: 2 +5 (so far we have 7) -3 (oops, back down to 4) annnd +50 . Hmm. It appears that we are left with 54. Again. I suppose we could do it in another order: -3 (negative 3) +2 (negative 1) and +5 (now we are back up to 4) annd that +50 again. Shucks, 54 again. Ok, how about 50 + 5 -3 +2 ... Hmmm.. STILL 54. Ok, I am curious. Is there any combination of 2, 5, 50, and -3 that you can think of that does NOT total 54 ? Now before you run loose again, I know where you are losing your grip here. You are thinking of these numbers as mere intergers, and as the +'s and -' as 'operators'. While this may be technically correct, you are missing the fact that these are VALUES, and you cannot separate the intergers from the operators in the original problem, or you have CHANGED THE VALUES, and therefore you have CHANGED THE NUMBERS. When you change the order of the VALUES in a simple addition/subtraction problem, you CANNOT break apart the intergers from the operators. It is utter nonsense to think that you can. This is why I tried to get you to think in terms of debits and credits, because a debit is a VALUE of -X and a credit is a VALUE of +Y. They are inseparable. Now, having said that: yes, if you simply took the numerals in the problem, and, willy-nilly, without regard to their actual values, and rearranged both the numerals AND the +'s and -'s, then yes, the sum would be different. But they would not be the SAME NUMBERS. -2 is not the same as 2. 3 is not the same as -3. Etc etc. So, congratulations. You have successfully proven that different numbers will add up to different sums. This cannot possibly be unclear now.
While i don't agree with your answer to the original equation that started this thread, you are correct in this assessment. rearranging the numbers in a addition/subtraction equation doesn't change the outcome. however, what jw1144 is doing is not rearranging, but changing them the value as you say.
Without a doubt, I got 2 as the answer. Then I see the trap. But I will still stick with my answer. If the formula is written as 48÷2x(9+3), then 288 for sure. I blamed calculus training that created the discrepancies. You know, the f(x) thing cemented an idea to us that something attached a function (the bracket) would have to be calculated first. I am thinking, for those who said 288, what would you get if the formula is presented as follows: 48÷(1+1)(9+3)
K I don't know what to believe anymore. Everyone is making valid arguments that I can see myself agreeing too. If it's not 2, then I am sorry. I am an idiot??
Trying to simplify this. All I'm trying to show is that the same associativity rules that apply to multiplication/division also apply to addition/subtraction. You must work from left to right. Nero keeps converting from subtraction to addition operators to prove that you don't need to worry about left to right. What I'm unsuccessfully trying to show is that IF YOU DON'T CONVERT THE ENTIRE EQUATION FROM SUBTRACTING POSITIVE INTEGERS TO INSTEAD THE ADDITION OF A NEGATIVE INTEGER and simply subtract the integers without conversion, you do indeed need to worry about the order of things. You wouldn't ever need to worry about the order of things in the multiplication/division side either if you first converted the entire equation from dividing integers to instead multiplying by their fractional inverse. This post tried to illustrate what would happen if the people in this thread getting an answer of 2 followed the same approach in the addition/subtraction world. But I guess he did not succeed either: http://bbs.clutchfans.net/showpost.php?p=6060829&postcount=249
If I remember order of operations correctly you have to take care of parenthesis before you multiply/divide so the answer would be 2. But what do I know right?
FYI : Wolfram Alpha/Mathematica says the answer is 288. Google says the answer is 288. Matlab says the answer is 288. Windows calculator says the answer is 288. C# says the answer is 288. :grin:
He did not succeed because there's no parenthesis, which is the core issue that created the discrepancies here, in his illustration at all.
