Thank you. I’ve trained my eyes to automatically skip past these problems when I see them on social media for just this reason.
It think that its more that people who spent far too many years in academia playing with equations realize that it is fixated on the least important aspect of mathematics, i.e. its notation, and in so doing misses its purpose.
The purpose of annotation is to provide a way for mathematicians to communicate ideas to each other. We teach PEDMAS to students because that is a convention that usually allows for these ideas to be conveyed precisely and unambiguously. So students should learn it so that they can successfully interpret the idea that is trying to be conveyed.
But in this case the writer of the expression is not trying to convey information they are trying to obfuscate it. If I was confronted with it in practice and asked to interpret it I would not try 5th grade PEDMAS since I wouldn’t necessarily trust such an imprecise author to follow the rules the way I would. Instead I would make some grumble under my breath about their intellectual abilities and try to go back to see where this expression came from so I could derive its intended meaning.
I think that part of the problem is that the most efficient way to build up students skills in mathematics is to give them lists of expressions and equations, and so they get the idea that interpreting and solving these sets of symbols that come out of the nowhere is what mathematics is all about. Its the equivalent of going through several sessions of football practice and assuming that the game of football consists of running through rows of tires, throwing a ball through hanging tires and pushing sleds around the field.
There are also a few (groan) word problems scrimmage matches at the end of practice but since they have nothing to do with tires they are really confusing so we don’t pay attention to them.
Strong arguments for RPN in this thread. That said, the whole issue is pointless. If you use RPN, there is no question. If you don’t, you are stuck with an arbitrary and non-obvious rule. And any mathematician will use parens to disambiguate any argument. I recently wrote a paper in which I corrected U+V+U\cap V to put parens around U\cap V.
I often end up writing something like this (though with /,* instead of ÷,× – and of course ‘()’ would be needed around ‘¾’) when using my favorite calculator: bc on a Unix terminal, e.g. where the up-arrow key provides access to previously entered commands.
It’s good to understand the precedence rules of bc when doing this but fortunately they’re mostly the same rules as C and many other systems. (Was a YouTube posted about a system with the other rule? What system was that?)
My point was the opposite - when it’s not a click-bait question, when it’s an expression with a purpose - as it is in academia generally - then it is important to avoid ambiguity. Since it has a purpose, it’s meant to be used for a real world purpose, an expression should - must - avoid ambiguity.
When it’s clickbait, superficial “ambiguity” with notation trickery is the whole point of it.
I’ve never seen 1/xy meant to be y/x, as I said gnerally ommission of the operation sign for multiplication implies it takes precedence over written signs; but like I said, that’s something I absorbed through osmosis, not explicit rules; because where an ambiguity is possible, like that, the point is to write it in such a way as to avoid the ambiguity - indeed the whole point is to avoid possible misinterpretation.
After all, why write 1/xy when you can write y/x? But more often than not, I see such expressions with brackets. 1/(xy) for just that reason also.
Yeah, I was just arguing for the use of RPN in calculation, which has unfortunately fallen out of favor. I wrote an RPN parser as an adjunct library to the dynamics signals processing module I was writing for Python and it was actually really easy versus trying to implement some kind of BOSMAS parser but nobody liked it. Actually, just nobody liked using Python and wanted me to port all of the utilities back into Matlab because learning a language and environment that has advanced since the ‘Nineties was too bothersome and complicated but I’m not bitter.
In terms of expressing equations and relations in print form, I always press for maximum clarity and minimizing any possibility of ambiguity by using clearly formatted equations in dedicated blocks, and then I run up against people who want to write their equations out in Word or Powerpoint but don’t want to use the Equation Editor (which despite how much I generally hate Microsoft ‘solutions’ is pretty straightforward), and so they either end up producing something that is ambiguous or just flatly wrong, or else using parentheses like they are being sponsored by Big Bracket. I’ve tried to get them to just use a WYSIWYG equation editor with a LaTex backend (having given up on getting people to just write their technical papers and documents in LaTex entirely) but the company in its finite wisdom decided that all online editors are a massive security threat and blocks them, never mind the employee data system that has been hacked more times than an old tree sticking out into the roadway or that timekeeping system which still has the default admin account and password enabled.
I had a point when I began this mathematical rant but it has since disappeared like a mathematical genius who doesn’t have time for your bullshit unless you pay him a decent retainer. Now the business we have heretofore you can speak with my aforementioned attorney. Good day gentlemen, and until that day comes, keep your ear to the grindstone.
Stranger
I remember playing with Forth a little bit, back in the late 80’s. One PLC unit came with that as the default language. It was a stack based language, including the ability to stack subroutines defined as “words” in the language, was siimple and efficient - and unambiguous.
Not just Forth. The Postscript language and thus PDF is also stack based. We see a lot of low level stack systems. The original Pascal compiler targeted the P-machine which was a simple portable stack machine. The modem world sees the Java Virtual Machine as an extension of this idea.
Stack architecture like this made for really easy expression compilation. Heck it was a common second year comsci assignment to write a simple expression, term, factor parser and walk the tree spitting out prefix, infix, and postfix versions of the input, and to write a stack based interpreter to run postfix expressions so parsed. I wrote one in Pascal on punch cards. (Kids of today, and get off my lawn, etc)
It wasn’t really until the success of the register colouring algorithm, and RISC with lots of registers that the underlying metal moved on from all stack based expression evaluation.
I’m in the pry my HP calculator from my cold dead hands camp. Performing simple arithmetic with infix notation is just wrong.
Facebook is full of those “I bet you can’t solve this” problems. There are always (at least) two solutions - depending on what order of operations you use. Of course - there are immediately 500 posts arguing that their solution is correct and not the other one.
And it’s always falling into 4 buckets: 1) absolutely no clue about math 2) people that follow PEMDAS literally 3) people that got a gold star last time they took math and remember it’s PE(MD)(AS) 4) people that do math and recognize it’s an ambiguous question designed to cause an argument and go viral. Possible 5th is I guess people that learned BEDMAS or whatever, but really that’s just an asterisk for 2 and 3.
Dunning-Krueger being what it is, your group 1 represents the largest fraction of responses and group 4 the smallest.
It’s not ambiguous under the rules, and it’s also not ambiguous under the rules. The problem is that the rules give a different answer than the rules. Or to put it more clearly, there is more than one set of rules, and they disagree here.
That’s kind of the definition of ambiguity.
So would I. IME, the convention is that whatever is on the left side of a ÷ symbol is the numerator of a fraction, and everything on the right side is the denominator.
They don’t get to change that without consulting me.
Yes, the method does assume an extra set of parenthesis so 6 ÷ (1(1+2)) = ?, but the method that produces a result of 6 does too. (6 ÷ 1)(1+2). In the absence of an adjudicator who can be consulted on the question of which set of assumed parentheses will prevail, whatever is on the left side of a ÷ symbol is the numerator of a fraction, and everything on the right side is the denominator.
Now go away, and take your clickbait with you (this is on the assumption that the original trick question came from Facebook).
I have a beautiful RPN calculator on my computer and would use nothing else. It is perfect for doing tax returns by hand since you are doing exactly that.
And Forth was a wonderful language. I wrote a small TeX interpreter in it. Stack based and thus inherently RPN, you defined new procedures and they became new operators in the language that you could use just like the original primitive operators.
What possible difference does implied multiplication make? Multiplication is multiplication, implied or not.
I mean, it’s been discussed throughout this thread and at length in the Wikipedia article on order of operations.
You’re claiming that 1/xy = y/x?
That’s how I read it too.
It’s the same as (1/x)*y. What else could it rationally be??? Multiplication and division have left to right precedence. Without a rule like that you could just make up any old crap.
It’s all any old made up crap. You could just as well say that 1/xy = \frac{1}{xy}, and couldn’t rationally be anything else, and without a rule like that you could make up any old crap. Which is in fact what some mathematical style guides do say.
Again: There is more than one widely-used convention for order of operations. Any of them works just fine, as long as the author and reader both know what convention is being used. None is more “inherently right” than any other.