Originally posted by Wingracer:
quote:Interesting that they are the same brand of calculator. Even the same manufacturer can't agree.
Originally posted by Lisa:
Here is what happens when you punchh it into a calculator.
![[Big Grin]](biggrin.gif)
quote:two you say
Originally posted by King of Men:
Two your own homework.
quote:It also has rigorous rules. You can't look at an expression and intuit exceptions to those rules.
Originally posted by PSI Teleport:
Except that math exists for a reason, Xavier.
quote:Yes, it absolutely does.
48 / 2b
Does 48/2 take precedence is this instance? I find that hard to believe.
quote:I knew THAT as soon as I saw who had posted the thread.
Originally posted by Xavier:
By the way, this is apparently a meme now
![[Smile]](smile.gif)
]
quote:Just to be clear, you're taking the position that 48 / 2b is the same as 24b?
Originally posted by Xavier:
quote:Yes, it absolutely does.
48 / 2b
Does 48/2 take precedence is this instance? I find that hard to believe.
48 / 2(12) = 48 / 2 * 12 = 288
You can't just choose to ignore math conventions when it suits you. Or at least you can't if you want to actually pass a math class.
Just write it as 48 / (2 * 12) if you want to represent the english egg problem you have above in math notation.
quote:Agreed.
Originally posted by mr_porteiro_head:
Whether in math or programming, if your expression is dependent on remembering whether operations are handled from left to right or right to left, it should probably be re-written to be clearer.
unambiguous != clear
quote:I'm interested in that as well, since so far I haven't heard of any software that says anything other than 288. If such exists (and is in wide use), then I will admit that a controversy exists and back away slowly
BTW, I'm not ignoring the calculator references you've given. Everything I've read on this issue so far says that different software computes this problem differently. I'm interested in which software gives the answer as "2." Not that you know. I'm just musing.
![[Wink]](wink.gif)
.quote:It is language-dependent.
Everything I've read on this issue so far says that different software computes this problem differently.
code:if(pointer && pointer->IsHappy())
{
.....
}
quote:Really? What's "i" then?
You can't just choose to ignore math conventions when it suits you.
quote:Well, for operations with the same precedence level this is true (which multiplication and division are, of course, so for this case yes I'll grant that this objection is something of a side note). The precedence levels are set up such that multiplication and division are equal, with addition and subtraction equal to each other but lower precedence (just like these operations are handled in math done outside a computer).
Originally posted by mr_porteiro_head:
[QUOTE]
C/C++, for example, explicitly specify that the order of operations is from left to right. Python (which is written in C) does the same.
quote:it is a weird controversy to be sure, but it's neat to me. How it gets worked out and all that.
Originally posted by Xavier:
I put it in an edit, so maybe you didn't see it:
Sources that say 288:
- WolphramAlpha
- Matlab
- Python
- My TI-89 calculator
Where is the controversy exactly?
quote:if I can find them, i'll shoot them for you
Originally posted by King of Men:
Yeah, ok, 288. But whoever wrote the expression that way should be shot for lack of clarity.
quote:IIRC, Lisp has no precedence levels, and operations must be explicitly ordered with parentheses.
Wikipedia tells me that APL and Smalltalk have no precedence levels, and that operators in these languages are evaluated strictly right to left and left to right, respectively.
![[Embarrassed]](redface.gif)
![[Razz]](tongue.gif)
quote:If it bores you, don't involve yourself.
Originally posted by jebus202:
It's boring there, and it's boring here. Find better material, Samp.
quote:It's PEMDAS here. I liked finding out about all the european ones.
Originally posted by Teshi:
I teach BIDMAS (or BEDMAS or PEDMAS or PIDMAS depending on which words you use, sigh) to my maths classes.
quote:You ignore i, pi vs. Tau, and the parallel postulate, and focus on my hyperbole? (that's a joke, son)
Edited also to add in responce (sic) to Glenn:
Except this is completely different than the topic at hand. We can prove that pi =/= 3. Proving that something previously thought to be correct is not correct will cause mathematical conventions to change, but that's not ignoring something "when it suits you", it's ignoring something because it's wrong.
quote:I think you are misunderstanding the debate on Pi vs Tau. Just because C = τr doesn't mean that C = 2πr is somehow incorrect. Those in favor of Tau are simply suggesting that we should default to using Tau in those equations because Pi is a bit clunkier. I don't see how this has anything to do with ignoring the standard order of operations.
You ignore i, pi vs. Tau
quote:Can you give an example where they don't?
But the current rules don't eliminate ambiguity.
quote:That's actually a great analogy for this, but it doesn't help your point. People who write in Hebrew have decided that it is to be read right to left, in a pretty analogous way to how mathematicians decided on the standard order of operations. What you are suggesting is that we should ignore standard conventions and write Hebrew left to right because we feel like it. You are the one suggesting we break from current conventions, not us.
One might just as well say that Hebrew must be read left to right because it's the correct way to read.
quote:They do in this case.
But the current rules don't eliminate ambiguity.
quote:See, and I'd say that 48/2x = 24/x.
Originally posted by Xavier:
Edit: This response is to Lisa.
The ÷ sign seems to be confusing you. Replace it with "/" and it becomes clear.
48/2x = 24x
quote:I disagree. I teach algebra, and when I have students who have been taught Order of Operations incorrectly, I have to re-teach it, otherwise I get students who will simplify this incorrectly:
Originally posted by King of Men:
Eh. I'm all for having competent math teachers, but there's such a thing as a priority. If the answer depends on getting the order of operations right, UR DOIN IT RONG. Put in some dang parens.
quote:I'm confused here Lisa. Do you think that it should be 24/x, or that it is 24/x (by current notational standards).
See, and I'd say that 48/2x = 24/x.
quote:Since when? Addition and subtraction are done from left to right, without any regard for which is first.
Originally posted by Jeorge:
Because you do addition before subtraction,
quote:Did you read my posts in their entirety?
Originally posted by Lisa:
quote:Since when? Addition and subtraction are done from left to right, without any regard for which is first.
Originally posted by Jeorge:
Because you do addition before subtraction,
Because that was exactly my point! There are teachers all over the place who teach it incorrectly, so by the time I get students in high school, they have it ingrained that you do addition before subtraction, even though that's not correct.
quote:Yeah, and sometimes it is simply mis-learning, but I've had enough inquiries from teachers to know that it's also mis-learning on the part of the teacher.
Originally posted by Teshi:
I can say it may not necessarily be what they are taught, only what they have learned.
![[Frown]](frown.gif)
quote:I think you are misunderstanding my argument. Pi is a convention. It is currently argued (we'll see if the convention changes) that Pi is inelegant, and the convention should be changed so that it is easier to understand.
I think you are misunderstanding the debate on Pi vs Tau.
quote:Ah. this proves you don't understand my argument. I'm not suggesting that we ignore conventions. I'm suggest we improve them.
What you are suggesting is that we should ignore standard conventions
quote:Yes. This one. It's pretty obvious that the question was asked to begin with because the OP recognized that many people would find the problem ambiguous. And then, a Ph.D physicist (among others) gave the "wrong" answer. As I said in my first post in this thread, the problem here is that these numbers are laid out purely for arithmetic's sake. Assuming that there is a real world problem that these numbers represent, investigating that problem may well reveal that the arithmetic is not laid out in accordance with the rules of order of operations. Order of operations is irrelevant. What's important (in all math problems) is reality.
quote:But the current rules don't eliminate ambiguity.
Can you give an example where they don't?
quote:Semantics.
What it lacks is clarity -- it's far too easy for a human to misread it, as evidence by the multiple people who are comfortable and experienced with mathematical notation getting it wrong.
quote:Interesting that they are the same brand of calculator. Even the same manufacturer can't agree.
Originally posted by Lisa:
Here is what happens when you punchh it into a calculator.
quote:What if this equation was for determining the minimum safe number of bolts needed for a bridge section and the correct answer in reality is 288? You just built a bridge that will collapse and kill many people when those 2 bolts fail.
Originally posted by Lisa:
After pondering this question, I've come to the conclusion that the correct answer is 2.
quote:Scholarette is right. The rules are clear. First you do the operation that is in parentheses, then you do exponents, then multiplication (in the order in which its written), then addition (in the order in which its written.
Originally posted by scholarette:
There is no ambiguity. 2 is wrong. 288 is right.
quote:Yikes!!
Originally posted by Wingracer:
quote:Interesting that they are the same brand of calculator. Even the same manufacturer can't agree.
Originally posted by Lisa:
Here is what happens when you punchh it into a calculator.
quote:If you're doing a mechanics problem, you just don't put it that way. This question can really only arise theoretically or in a poorly written math text.
Originally posted by Wingracer:
quote:What if this equation was for determining the minimum safe number of bolts needed for a bridge section and the correct answer in reality is 288? You just built a bridge that will collapse and kill many people when those 2 bolts fail.
Originally posted by Lisa:
After pondering this question, I've come to the conclusion that the correct answer is 2.
quote:If you're doing any implying or inferring, you're not using standard mathematical notation. If you follow the rules of standard notation, there is one and only one answer.
positioning two expressions adjacent to one another in order to signify multiplication carries with it an implicit grouping
quote:The two concepts usually go hand in hand, but the differences between them are pretty important in this situation.
Originally posted by Glenn Arnold:
quote:Semantics.
What it lacks is clarity -- it's far too easy for a human to misread it, as evidence by the multiple people who are comfortable and experienced with mathematical notation getting it wrong.
quote:So then you'd say that 48/2x (or 48÷2x) is equal to 24x? And not 24/x?
Originally posted by mr_porteiro_head:
quote:If you're doing any implying or inferring, you're not using standard mathematical notation. If you follow the rules of standard notation, there is one and only one answer.
positioning two expressions adjacent to one another in order to signify multiplication carries with it an implicit grouping
quote:This problem arises all the time and has nothing to do with poorly written math texts. It comes up whenever you need to enter a long mathmatical formula into a computer. The solution to this problem is NOT to use more brackets. It is far too easy to make errors when you use lots of nested parentheses and far too difficult to find those errors. The standard student approach seems to be "When in doubt, add some more brackets. I've helped hundreds of engineering students debug/troubleshoot computer problems and virtually without exception, the more parentheses they've used, the more likely they are too have an error in their formula and the harder it will be to find that error.
If you're doing a mechanics problem, you just don't put it that way. This question can really only arise theoretically or in a poorly written math text.
quote:Rabbit makes a point -- I run into this sort of thing all the time in programming.
Originally posted by The Rabbit:
quote:This problem arises all the time and has nothing to do with poorly written math texts. It comes up whenever you need to enter a long mathmatical formula into a computer. The solution to this problem is NOT to use more brackets. It is far too easy to make errors when you use lots of nested parentheses and far too difficult to find those errors. The standard student approach seems to be "When in doubt, add some more brackets. I've helped hundreds of engineering students debug/troubleshoot computer problems and virtually without exception, the more parentheses they've used, the more likely they are too have an error in their formula and the harder it will be to find that error.
If you're doing a mechanics problem, you just don't put it that way. This question can really only arise theoretically or in a poorly written math text.
quote:While this is true of the example in the subject bar, I did see this sort of thing pretty commonly in my way to my Math minor:
That's the rule (24x). I think you have a reasonable case that many people would interpret it otherwise, but that's not how the rules work. The currently accepted way of interpreting mathematical expressions would render it as 24x, full stop. Of course, the real rule in such a situation is to not write things in such an annoying way. You'd never see somebody who writes down mathematical expressions in the normal course of things ever write an expression so annoyingly.
quote:My experience leads me to the opposite conclusion. The more parentheses people use, the harder it is to decipher a long formula in code. It's too easy to mistake which close parenthesis goes with which open parenthesis. Yes, you can break it up by introducing new variables that play the same role, but when the formula has some physical meaning (as they nearly always do in engineering) introducing dummy variables makes it harder rather than easier to decipher what's going on.
n my experience, it's far better to use parentheses than to rely on the order of operations being left-to right. Not because the left-to-right order of operations cannot be depended on, but because it makes the expression much more difficult for humans to read and decipher.
quote:I'm assuming you are not using the proper mathematical definition of a proper fraction? As it would be quite improper to imply that this does not properly apply to improper fractions as well...
Originally posted by Nighthawk:
a proper fraction
quote:That's irrelevant. If you need to enter the formula into a computer program, it's still most commonly done in a single line. Since being able to enter mathematical expression into computer programs is an important skill, people need to know how to do it.
Originally posted by Nighthawk:
But how many curriculums still write fractions like that, as a single line, and not as a proper fraction with a horizontal dividing line, where numerator and denominator are clear?
quote:I'm not using the mathematical term. I mean "proper" in terms of display, as far as it is written: numerator and denominator.
Originally posted by Jeorge:quote:I'm assuming you are not using the proper mathematical definition of a proper fraction? As it would be quite improper to imply that this does not properly apply to improper fractions as well...
Originally posted by Nighthawk: a proper fraction
quote:But entering it as written above, at least in most of the programs I know of, will yield an error. Can't enter it exactly as written in Excel or most of the programming languages I know. And as far as I know (it's been a while since I use it) programs like Mathematica explicitly require entering it in fraction form.
Originally posted by The Rabbit:
quote:That's irrelevant. If you need to enter the formula into a computer program, it's still most commonly done in a single line. Since being able to enter mathematical expression into computer programs is an important skill, people need to know how to do it.
Originally posted by Nighthawk:
But how many curriculums still write fractions like that, as a single line, and not as a proper fraction with a horizontal dividing line, where numerator and denominator are clear?
quote:That's really irrelevant. The terms 3x2, 3*2, 3(2), and 3*(2) mean exactly the same thing. 3/2,3÷2 and 3 over 2 mean exactly the same thing. The fact that some computer programs will accept only a subset of those terms is why its important to understand that they mean exactly the same thing. The fact that we calculate so many things using computer programs is a large part of why its important to understand the standard rules for the order of calculations.
But entering it as written above, at least in most of the programs I know of, will yield an error.
quote:These days, any code editor worth its salt makes it very easy to tell which parentheses are paired. In many, if you put the cursor on one parentheses (or bracket, or quotation mark, etc.), the paired one is hilighted, bolded, etc.. Its pretty easy to read multiple nested parentheses when the editor does that for you.
My experience leads me to the opposite conclusion. The more parentheses people use, the harder it is to decipher a long formula in code. It's too easy to mistake which close parenthesis goes with which open parenthesis
quote:I still disagree. Both matlab and excel have this feature and I still find that the more parentheses used in a formula, the harder it is to decipher the formula. I help students try to trouble shoot these things daily and the more parentheses they've used, the more likely it is that they've made an error and the harder it will be to find that error. I've taken to starting by deleting all the unnecessary parentheses since this is often the only way to sort out which set of parentheses is wrong.
Originally posted by mr_porteiro_head:
quote:These days, any code editor worth its salt makes it very easy to tell which parentheses are paired. In many, if you put the cursor on one parentheses (or bracket, or quotation mark, etc.), the paired one is hilighted, bolded, etc.. Its pretty easy to read multiple nested parentheses when the editor does that for you.
My experience leads me to the opposite conclusion. The more parentheses people use, the harder it is to decipher a long formula in code. It's too easy to mistake which close parenthesis goes with which open parenthesis
quote:Porter said
Porter has noted, actual code editors make parentheses trivially easy to pair up.
quote:I'm perfectly willing to believe there are better code editors but both matlab and excel have the feature Porter descibes. It's certainly helpful but I still find it very tedious to decipher formulas that contain many nested parentheses.
In many, if you put the cursor on one parentheses (or bracket, or quotation mark, etc.), the paired one is hilighted, bolded, etc.. Its pretty easy to read multiple nested parentheses when the editor does that for you.
code:Y =
(
5/(0.25^2)
)
*
(
(
(
T1-(2*T2)/0.25+T3) / (2*(0.1^2)
)
)
-
(
1/(0.25^2)*(T3-T1) / (2*0.2)
)
+
(
(1/2)*T1
)
)
code:Y =
(
5/(0.25^2)
)
*
(
(
(
T1-(2*T2)/0.25+T3
)
/
(
2*(0.1^2)
)
)
-
(
1/(0.25^2)*(T3-T1) / (2*0.2)
)
+
(
(1/2)*T1
)
)
quote:The first is correct. The second has an error. How quickly can you find the error in the second.
Originally posted by mr_porteiro_head:
The second. It's not even a contest.
quote:Yup. When I went to find the error in the second one, the first thing I did was start carefully adding parentheses to the first one so that I could tell what it was actually doing.
In order for us to find an error in the second using the first as authoritative, we'd have to be confident that we're parsing the first one correctly. Which, frankly, I'm not; the first is considerably harder to parse.
quote:Curious. To find the error in the second one, I first go through and remove all the unnecessary parentheses. I parse the first one correctly essentially instantaneously.
Originally posted by mr_porteiro_head:
quote:Yup. When I went to find the error in the second one, the first thing I did was start carefully adding parentheses to the first one so that I could tell what it was actually doing.
In order for us to find an error in the second using the first as authoritative, we'd have to be confident that we're parsing the first one correctly. Which, frankly, I'm not; the first is considerably harder to parse.
quote:And my method is to add parenthesis to the first one. When dealing with a complex expression (or query) that is not producing the results I expect, I start using parenthesis to logically group key components so they can be more easily considered in isolation of the other components.
Curious. To find the error in the second one, I first go through and remove all the unnecessary parentheses. I parse the first one correctly essentially instantaneously.
quote:She didn't just divide by two -- she multiplied by one divided by two.
By the way, who divides by 2 when they can multiply by 0.5?
quote:Me, too.
Originally posted by SenojRetep:
I agree with Porter, Matt, and Tom: I believe I could find an error in an equation with more parenthesis faster than in one with fewer.[
quote:I'm one of those people. I had to become proficient at HP notation for advanced calculus, chemistry and physics classes. Once I finished with undergraduate and could chose my own resources, I happily left Reverse Polish behind.
Originally posted by The Rabbit:
Its really hard to find someone who has become proficient with the HP notation that doesn't prefer it.
quote:Interestingly, I have discovered that in matlab using certain computer processors, dividing by 2 and multiplying by 0.5 give slightly different results. Not that differences out at the 15th and 16th decimal points are commonly of importance, but they are there.
Originally posted by mr_porteiro_head:
quote:She didn't just divide by two -- she multiplied by one divided by two.
By the way, who divides by 2 when they can multiply by 0.5?
quote:Hm. This is actually rather interesting. Which is more accurate?
Interestingly, I have discovered that in matlab using certain computer processors, dividing by 2 and multiplying by 0.5 give slightly different results. Not that differences out at the 15th and 16th decimal points are commonly of importance, but they are there.
quote:That is interesting. Both 2 and 0.5 can be expressed in IEEE-754 binary floating point without rounding issues. I'd be really curious to see an example of an equation that produces different results depending on whether you divide by 2 or multiply by 0.5.
Originally posted by The Rabbit:
quote:Interestingly, I have discovered that in matlab using certain computer processors, dividing by 2 and multiplying by 0.5 give slightly different results. Not that differences out at the 15th and 16th decimal points are commonly of importance, but they are there.
Originally posted by mr_porteiro_head:
quote:She didn't just divide by two -- she multiplied by one divided by two.
By the way, who divides by 2 when they can multiply by 0.5?
). Find the error and post your corrected version. Please rank them in terms of how hard it was to find the error. Please report any software you used to help parse the formulas.quote:It's not making a mistake per se. It's a difference in round off error for floating point numbers. I don't think the problem is in matlab itself, because it occurs on some processors but not others. I discovered it when I was devising problems that demonstrated computer round off error.
Originally posted by mr_porteiro_head:
That's a problem with using a proprietary language like Matlab -- it's impossible to find out what's going on behind the scenes if it's making mistakes.
quote:I found this humorously ironic.
Originally posted by The Rabbit:
This question has me interested (for instructional purposes. I'd appreciate anyone who is willing to answer all or part of the question.
quote:
Originally posted by Sean Monahan:
quote:I found this humorously ironic.
Originally posted by The Rabbit:
This question has me interested (for instructional purposes. I'd appreciate anyone who is willing to answer all or part of the question.
quote:I went through each one, correcting it as I went. Some of my "corrections" wouldn't actually change the result, such as it adding parentheses that weren't strictly needed.
The following set of formulas are each missing one close parentheses (I hope [Big Grin] ).
code:The first differnece is between 1/r and (1/r). Looking back, I can see that I just kept that as whatever the first one was. I felt no need to add or remove those parentheses.1. y = D*(1-1/r) *((c1-2*c2+c3)/(dr^2)+(2/r)* (c3-c2)/(2*dr)) +k*(a*r-b)*c2
2. y = D*(1-(1/r)) *((c1-2*c2+c3)/(dr^2)+(2/r)*((c3-c2)/(2*dr)))+k*(a*r-b)*c2
quote:
*eta: For example, a*b*c*d*e*f/g needs no parentheses to be clear, because it doesn't matter what order you do the multiplication and division, but a*b/c*d/e*f/g would need several.
quote:Are these modern processors? There were known floating-point bugs in some older CPUs, years ago, but I'd be astonished if this were still happening. Do you have examples?
It's a difference in round off error for floating point numbers.
quote:Yes, these are modern processors. Round-off error is machine dependent. I'm not sure exactly why a/2 gives a very slightly different answer than 0.5*a, but it does, at least on some current machines. Like I said before, the difference normally occurs out at the 15th or 16th decimal place using double precision floating point representation.
Originally posted by TomDavidson:
quote:Are these modern processors? There were known floating-point bugs in some older CPUs, years ago, but I'd be astonished if this were still happening. Do you have examples?
It's a difference in round off error for floating point numbers.
quote:Sidenote: Did you play Mass Effect 2?
Originally posted by TomDavidson:
quote:Are these modern processors? There were known floating-point bugs in some older CPUs, years ago, but I'd be astonished if this were still happening. Do you have examples?
It's a difference in round off error for floating point numbers.
quote:While I can see that being possible, it would actually be irrelevant to the evaluation of an expression. When the expression is actually evaluated, any integer values would need to be promoted to floating point values so the binary floating point value would come into play then.
Originally posted by mr_porteiro_head:
The 2 is likely being stored as an integer, not in binary floating point.
quote:Woops, yes I meant to say that I'm so accustomed to applying the standard order of operations that it actually took me some time to figure out why you thought the second case was any different than the first.
Originally posted by mr_porteiro_head:
Rabbit, did you mean to say something in the above post where you quoted me?
quote:Speaking for myself, it's not the order of operations that's confusing, but the sheer volume of data. When you have different operations with different OOO priority scattered throughout a lengthy, complex equation, the mental stack necessary to keep everything in order can be confusing.
I'm genuinely surprised to see how many math and computer literate adults find the standard order of operations to be confusing.
quote:Ditto. I was never a fan.
Originally posted by CT:
quote:I'm one of those people. I had to become proficient at HP notation for advanced calculus, chemistry and physics classes. Once I finished with undergraduate and could chose my own resources, I happily left Reverse Polish behind.
Originally posted by The Rabbit:
Its really hard to find someone who has become proficient with the HP notation that doesn't prefer it.
quote:Obviously you are correct, though as I said before I find that a genuine surprise.
So, sod the order of operations, that problem without parens is just plain misleading.
quote:This.
Originally posted by rivka:
Pfft. The fact that PhD'd mathematicians and physicists can't do basic arithmetic is a well-documented phenomenon.
(In the days of print catlogs) the AMS had to print a separate catalog for members, because many of them couldn't calculate 20% off consistently.
quote:As a general rule I agree. When I am coding long formulas, I very commonly do something like SenojRetep suggested because its so much easier to "debug" each little piece.
Originally posted by TomDavidson:
*nod* Since you resolve and design each unit separately, it's easier to "debug" through unit testing even if the overall picture is murkier.
quote:But it definitely makes the overall picture of what I'm doing murkier. If I do this when I'm trying to show less advanced students how to work a problem, they have a terrible time following what I'm doing.
In this case, if I were writing the formula you provided, I would do it as:
f1 = (1-1/r);
f2 = (c1-2*c2+c3)/(dr^2);
f3 = 2/r*(c3-c2)/(2*dr);
f4 = k*(a*r-b)*c2;
y = D*f1*(f2+f3)+f4;
quote:was the optimal number of brackets, was what I expected. It has two more sets of parentheses than case number 1. One set is completely unnecessary (dr^2), the other (2*dr) can be eliminated if you change the operator. I agree that changing "/dr/2" to "/(2*dr)" improves the readability of the equation. Adding the brackets around dr^2 just seems to make things more cluttered to me, but I can see how some people would find the lack of brackets ambiguous. Adding more brackets than #6 definitely makes it harder for me to decipher rather than easier.
6. y = D*(1-1/r)*((c1-2*c2+c3)/(dr^2)+2/r*(c3-c2)/(2*dr)+k*(a*r-b)*c2
quote:The formula gives the wrong answer because they've misplaced one of the brackets, but because they've used so freaking many unneeded brackets, it's a lot harder to find the mistake. (I'm not exaggerating, I've seen hundreds of students do this)
y = (((D*(1-(1/r)))*((c1-2*c2+c3)/(dr^2)+2/r*(c3-c2)/(2*dr)))+k*((a*r-b*c2)))
quote:No, if they'd learned to properly use parentheses, they wouldn't be making the mistakes in the first place.
They do this because they've learned to use brackets instead of understanding and applying the order operations.
quote:Yeah, agreed. The main issues here seem to be:
I wonder if there would be the same degree of confusion if the problem were written 48/2*(9+3) or 48/2(9+3) rather than 48÷2(9+3). Even though nearly everyone would agree that all three ways of writing it are identical, the visual spacing is different. I think when its written 48÷2(9+3), the spacing creates a visual break between the 48 and the 2 that makes one want to group the 2(9+3), when its written the other way 48/2*(9+3), the visual break works the opposite way.
quote:I doubt there'd be a huge debate over juxtaposition, but maybe I'd be wrong.
3/4(12) = ?
A) 9
B) 3/48
C) None of the above.
quote:Yes.
Edit: I'm also curious if Porter and others think the above should have been written as (3/4)12 or something.
quote:Well yes, granted. But in this case we're not making a simple mistake. Nobody is multiplying 2 by 12 and getting 25. We're all getting the same wrong answer! So it's not a question of simple arithmetical mistakes, but of mentally inserting the wrong parens.
Originally posted by rivka:
Pfft. The fact that PhD'd mathematicians and physicists can't do basic arithmetic is a well-documented phenomenon.
quote:I absolutely do.
I'm also curious if Porter and others think the above should have been written as (3/4)12 or something.
quote:Sure you are. The difference is of type, not degree, and it comes down to the rules of basic arithmetic.
Originally posted by King of Men:
quote:Well yes, granted. But in this case we're not making a simple mistake.
Originally posted by rivka:
Pfft. The fact that PhD'd mathematicians and physicists can't do basic arithmetic is a well-documented phenomenon.
.
quote:Well yes. We just did, by having our mistake pointed out to us.
Originally posted by The Rabbit:
The fact that you are all making the same mistake, suggests you all have the same deficiency. I'd suggest you all be required to enroll in a basic refresher course in arithmetic.