48÷2(9+3) = ?
Thread Rating:
But what's most interesting is that different models from the same brand calculator have conflicting answers. I would have expected, if anything, that the brands would differ, but all models from one brand would have the same result.
Very interesting.....
Quote: DJTeddyBear288.
But what's most interesting is that different models from the same brand calculator have conflicting answers. I would have expected, if anything, that the brands would differ, but all models from one brand would have the same result.
Very interesting.....
TI-85 had a bug, that got fixed in next version - TI-86
This is embarrassing for us.
(Resolve first (nested) parens [and brackets]))
Planet math:
http://planetmath.org/?op=getobj&from=objects&id=3951
Wiki (Hi, Bob!)
http://en.wikipedia.org/wiki/Order_of_operations
Quote: weaselmanTI-85 had a bug, that got fixed in next version - TI-86
Wikipedia entry:
An expression like 1/2x is interpreted as 1/(2x) by TI-82, but as (1/2)x by TI-83. While the first interpretation may be expected by some users, only the latter is in agreement with the standard rules
The TI-82 is a graphing calculator made by Texas Instruments. The TI-82 was designed in 1993 as a stripped down, more user friendly version of the TI-85.
Did you ever notice that Excel interprets -3^2 as +9 and not -9?
Quote: pacomartin
Did you ever notice that Excel interprets -3^2 as +9 and not -9?
That is correct. Unary operators have the highest precedence.
An argument could be made, I say incorrectly, for doing the multiplication before the division, per the Please Excuse My Dear Aunt Sally rule. This is a memory device for the order of operations. It would suggest doing parenthesis first, then exponents, then multiplication, then division, then subtraction, and addition last.
Where this is not quite right is multiplication and division are equal in priority, as well as addition with subtraction. When both are present, you go left to right. So somebody who took the PEMDAS method literally would do 48 / 2(9+3) = 48/2*12 = 48/24 = 2.
I agree up to the 48/2*12. Since multiplication and division are equal, you do the left operand first, or 48/2*12 = 24*12 = 288.
At school, I was taught the word BODMAS - Brackets Of Division, Multiplication, Addition, Subtraction to represent the order of performing the operations.
Quote: SwitchI go with 288.
At school, I was taught the word BODMAS - Brackets Of Division, Multiplication, Addition, Subtraction to represent the order of performing the operations.
I taught myself to not invite ambiguity. Even the calculators are confused.
It's not that the answers are wrong, it's that the rules have been taught differently. I see that as
48
--------
2(9+3)
Quote: dmI go with 2. If 288 is wanted then write it (48/2)(9+3)
The answer should be 288, but I don't think it was a bug. I think that the designers of the calculator believed that people who write 48/2*(9+3) usually mean to calculate 48/(2*(9+3)). But it is not the accurate interpretation. I think they did tests, and most people who meant to get the answer 288 would write (48/2)(9+3).
I doubt most people here remember the early days of programming, but originally programmers used to pride themselves on making very compact code that made all kinds of use of default characteristics of character types. It was discovered that "clever" programming often cost a fortune in debugging. We were told not to be "clever". Parenthesis are cheap. Just use a lot of them and make yourself clear.
Quote: dmI go with 2. If 288 is wanted then write it (48/2)(9+3)
If 2 was warranted then write it as 48/(2*(9+3)). Since neither was specified, it is proper procedure to go left to right.
Quote: MoscaI was always taught to do the brackets first. I got 2.
It's not that the answers are wrong, it's that the rules have been taught differently. I see that as
48
--------
2(9+3)
I say that 2 is flat out wrong. It is not a matter of opinion. Between multiplication and division, and lacking parenthesis, it is not optional to do it either way. You do the 9+3 first because it is inside the parenthesis, but there is no priority for 2*12 because the 12 was a result of parenthesis. Once you do the 9+3 the parenthesis effectively are removed. Then it is standard to go left to right, much like it is standard to read that way (except in Hebrew).
Quote: dmI go with 2. If 288 is wanted then write it (48/2)(9+3)
I say if 2 is wanted it would be 48/(2(9+3))
edit, the wiz beat me to it
Quote: SwitchI go with 288.
At school, I was taught the word BODMAS - Brackets Of Division, Multiplication, Addition, Subtraction to represent the order of performing the operations.
I go with 288 also, although I admit that my first instinct was 2. But using MDAS, you get ...
1. 48 / 2 * (9 + 3) - brackets first
2. 48 / 2 * 12
3. 24 * 12
4. 288
I think the confusion might come with MDAS being held to literally when in fact M and D are just inverse operations and should be done from left-to-right in the absence of more information. I think this is how Excel interprets it as well.
My $0.02. But an interesting question, esp. with the calculators!
EDIT: I think it's more accurate to say (MD)(AS), but it could just as easily be (DM)(AS). I think it would be a similar mistake to hold to DMAS literally.
Quote: WizardI go with 288 also.
An argument could be made, I say incorrectly, for doing the multiplication before the division, per the Please Excuse My Dear Aunt Sally rule. This is a memory device for the order of operations. It would suggest doing parenthesis first, then exponents, then multiplication, then division, then subtraction, and addition last.
Where this is not quite right is multiplication and division are equal in priority, as well as addition with subtraction. When both are present, you go left to right. So somebody who took the PEMDAS method literally would do 48 / 2(9+3) = 48/2*12 = 48/24 = 2.
I agree up to the 48/2*12. Since multiplication and division are equal, you do the left operand first, or 48/2*12 = 24*12 = 288.
Another useful schooldays mnemonic was Kevin, Please Come Over For Gay Sex. Honor point to anyone who knows what that's for!
It is 288, but I'd probably tell anyone writing it down to write (48/2)*(9+3) to be explicit and avoid confusion.
Quote: ItsCalledSoccerHonor point to anyone who knows what that's for!
Kevin Spacey?
Quote: pacomartinI think that the designers of the calculator believed that people who write 48/2*(9+3) usually mean to calculate 48/(2*(9+3)).
Could be ... However, they should have made the display reflect the correct formula in that case. So, I'll still say it's a bug.
Quote:I doubt most people here remember the early days of programming, but originally programmers used to pride themselves on making very compact code that made all kinds of use of default characteristics of character types. It was discovered that "clever" programming often cost a fortune in debugging. We were told not to be "clever". Parenthesis are cheap. Just use a lot of them and make yourself clear.
I cannot agree with that. In my experience, almost nothing has as much potential to pollute the code and make it unreadable as redundant and excessive parenthesis. I always laugh when people try to make this "argument" - a guy that calls himself a "programmer" but finds it hard to remember the precedence of arithmetic operators is pretty funny indeed.
Quote: weaselmanI cannot agree with that. In my experience, almost nothing has as much potential to pollute the code and make it unreadable as redundant and excessive parenthesis. I always laugh when people try to make this "argument" - a guy that calls himself a "programmer" but finds it hard to remember the precedence of arithmetic operators is pretty funny indeed.
I can see it happening, although I'm not excusing it. I would think that operation order would be so "basic" to programming that it's just a module they plug in. Can't blame the programmer for using a module he's been told works. No need to reinvent that wheel for every new product, I would think.
But yeah ... they should catch it when they run their tests.
Quote: weaselmanI cannot agree with that. In my experience, almost nothing has as much potential to pollute the code and make it unreadable as redundant and excessive parenthesis. I always laugh when people try to make this "argument" - a guy that calls himself a "programmer" but finds it hard to remember the precedence of arithmetic operators is pretty funny indeed.
I fall somewhere in the middle. I first learned to program Basic in high school in 1981 or 82, and have been programming ever since. In my opinion there definitely used to be more of an emphasis on being concise as a matter of style. However, you had to weigh that against it being obvious what a program was supposed to do from the source code.
Through the years, the emphasis has moved away from impressive tight code to easily understandable code.
Quote: WizardHowever, you had to weigh that against it being obvious what a program was supposed to do from the source code.
Yes, of course. I am not talking about being as concise as possible at all costs, as the main criteria. The priority is, of course, the readability and maintainability of the code. It is the definition of "readability" that is in question here.
((a+(((b*c)*((d^e)/(f^g))/h))-(i*(j^k)/(l^m))-(n*p) is not only longer, but also way more obscure than
a + b*c*d^e/f^g/h - i*j^k/l^m - n*p
Quote: WizardI say that 2 is flat out wrong. It is not a matter of opinion. Between multiplication and division, and lacking parenthesis, it is not optional to do it either way. You do the 9+3 first because it is inside the parenthesis, but there is no priority for 2*12 because the 12 was a result of parenthesis. Once you do the 9+3 the parenthesis effectively are removed. Then it is standard to go left to right, much like it is standard to read that way (except in Hebrew).
Ah, I see now. Thank you for the rundown. I don't work with arithmetic much, even though my work life is almost consumed by numbers they aren't really part of the job, they're just placekeepers. You wouldn't know I used to be quite good with them, I don't give them their proper place of importance any more.
Quote: ItsCalledSoccer
Another useful schooldays mnemonic was Kevin, Please Come Over For Gay Sex. Honor point to anyone who knows what that's for!
Kingdom, Phylum, Class, Order, Family, Genus, Species
Quote: iamthepushKingdom, Phylum, Class, Order, Family, Genus, SpeciesQuote: ItsCalledSoccerAnother useful schooldays mnemonic was Kevin, Please Come Over For Gay Sex. Honor point to anyone who knows what that's for!
Kevin, Please Come Over For Gay Sex OK?
Kingdom, Phylum, Class, Order, Family, Genus, Species, Orientation, (Kidding)
Quote: weaselman
I cannot agree with that. In my experience, almost nothing has as much potential to pollute the code and make it unreadable as redundant and excessive parenthesis. I always laugh when people try to make this "argument" - a guy that calls himself a "programmer" but finds it hard to remember the precedence of arithmetic operators is pretty funny indeed.[/q
The precedence of operators of the compiler you're using at the time? My 1980s code for Borland C may not, based on this thread, be parsed in the same way by current gcc or MSFT compilers. Parentheses can only clarify, not obfuscate.
I voted 2 as my background taught that parentheses do not get pooted out of the unicorn's ass when the inner expression is evaluated but remain and retain their precedence until the entire expression is completely resolved . Now I see that's a naive and foolhardy belief, and I'll (continue to) use parentheses to clarify the order of operations. ((Your editor can parse the redundant ones.))
Quote: DocKevin, Please Come Over For Gay Sex OK?
Kingdom, Phylum, Class, Order, Family, Genus, Species, Orientation, (Kidding)
I was taught Kelly but hey whatever floats his boat!
Quote: allenwalker
The precedence of operators of the compiler you're using at the time? My 1980s code for Borland C may not, based on this thread, be parsed in the same way by current gcc or MSFT compilers.
What does this thread have to do with ancient "C" compilers? Trust me, they did obey the rules of arithmetics.
Quote:Parentheses can only clarify, not obfuscate.
You are wrong. See my counter example in the above post.
Quote:I voted 2
Ah, that explains a lot about your position :)
Quote: allenwalker
The precedence of operators of the compiler you're using at the time? My 1980s code for Borland C may not, based on this thread, be parsed in the same way by current gcc or MSFT compilers.
What does this thread have to do with ancient "C" compilers? Trust me, they did obey the rules of arithmetics.
Quote:Parentheses can only clarify, not obfuscate.
You are wrong. See my counter example in the above post.
Quote:I voted 2
Ah, that explains a lot about your position :)
Kids...
Quote: weaselmanWhat does this thread have to do with ancient "C" compilers? Trust me, they did obey the rules of arithmetics.
It has to do with your comment on code maintenance. Hardware brevis, software longa. We all port old code to new platforms. And, while I trust you, this thread and its parent at physicsforum.com show that in this case of expression evaluation the rules are not clear.
Quote: weaselmanYou are wrong. See my counter example in the above post.
I missed anything other than your assertion that parentheses are evil.
Quote: weaselmanAh, that explains a lot about your position :)
Well, I offer no apologies for my parsing of the OP's expression, but that's separate from the issue of code clarity .
Quote: allenwalkerIt has to do with your comment on code maintenance. Hardware brevis, software longa. We all port old code to new platforms. And, while I trust you, this thread and its parent at physicsforum.com show that in this case of expression evaluation the rules are not clear.
What rules are not clear? To whom? If a professional computer programmer finds that the binding rules of simple arithmetic operators are unclear to him, he should really look into getting another profession.
Quote:I missed anything other than your assertion that parentheses are evil.
Well, too bad ... Trying reading again, maybe this time you won't miss that much ... or at least, notice that I have never made such an assertion.
Quote:Well, I offer no apologies for my parsing of the OP's expression, but that's separate from the issue of code clarity .
I don't think it is separate. I person, unable to parse mathematical expressions cannot have a valid opinion about code clarity. It would be like having a person, unfamiliar with Mandarin or Cantonese judge the clarity of a Chinese text.
Quote: iamthepushKingdom, Phylum, Class, Order, Family, Genus, Species
Honor point!
http://www.flickr.com/photos/60422092@N05/5622963267/
Quote: dmThere is no multiplication sign in the original so when you remove parenthesis you have 48/212=not 288. The parenthesis signs have to remain to imply multiplication with 2 so you do it first before division.
To play Devil's Advocate, I think that the problem stems from placing a number inside parenthesis. For example, 48 / 2 X 12 = 288 following the rules of operations.
We have an inclination to multiply out brackets so, by placing 12 inside parenthesis, albeit 3+9, the tendency is to multiply out the brackets. It's easier to see it if we use algebra, for example:-
If we were to solve the equation 48 / (2x + 2) = 1 we would work out that 2x + 2 = 48 so x = 23.
However, if we take the common factor outside the parenthesis we get 48 / 2(x + 1) = 1. Following BODMAS we would get 24(x + 1) = 1 so x + 1 = 1/24 and x = -23/24. So, in order to follow the correct order we would need to state 48 / (2(x + 1)) = 1.
Following that same logic, we should state 48 / (2(3 + 9)) as we would use that if letters were involved instead of numbers. We don't need a multiplication sign between the number and the parenthesis as the omittance of any sign implies multiplication. This would now give the answer as 2.
Unless, of course, different rules are applied to algebraic equations rather than numerical calculations???
I think it comes down to the definition of implied multiplication operator. It has commonly come to act as a separate operator from normal multiplication, specifically in having its priority right after exponentiation and ahead of basic arithmetics.
I see the point in that it's not formally defined. On the other hand, anyone reading c=f1(y)/kx as anything other than c="f1"(y)/(k*x) is going to read a lot of books wrong. When misunderstanding is a possibility, it's best just not to use any implied operators.
If necessary to read an existing notation, it should be deciphered relying on the context, like an archeological find.
Times have obviously changed, and methods are numerous, causing discrepency. I was taught the answer is 2, because the semantics of the parenthetical expression indicates the implied multiplication belongs to the parenthetical information.
To get an answer of 288 requires the expression to be written as 48/2*(9+3). Now, the multiplication is not implied, and counts as a general expression operation. Since the math problem is written as 48/2(9+3) I stand by the answer of 2.
BTW: My calculator indicates the answer is 4 when entered exactly as written: it does not know what operator to use between the 2 and the (. Therefore the calculator ignores the input, and solves what is known!
