Seems to me that either multiplication does have precedence over division (and, yes addition over subtraction but that doesn't matter) or it's read left to right.
So far we haven't seen anything from any mathematical paper or qualified person to say which way it goes.

Everyone I know who I have spoken to about this kind of thing who had some kind of maths attached to their university course at a UK university (granted that's perhaps half a dozen at most over the course of my life not including people in the exact same classes as me) was told that PEMDAS stands. So this is not simply something taught to children to be hand waved away.

I'm willing to be told that PEMDAS doesn't hold and left to right is the way - but I would like to see a definitive source.

The first random textbook I checked states that multiplication and division are of the same precedence and that they're evaluated from left to right. According to PEMDAS, in fact.

https://openoregon.pressbooks.pub/te...ter/chapter-1/

Thank you - it seems some of us were either taught wrongly or not clearly enough.

Perhaps you didn't read my previous post where in the wikipedia article the sources were physics journals/books which I copy and past to below again:

I'll add this also:

It depends what source you use. Here multiplication "is of higher precedence than division."

Mixed division and multiplication

In some of the academic literature, multiplication denoted by juxtaposition (also known as implied multiplication) is interpreted as having higher precedence than division, so that 1 ÷ 2n equals 1 ÷ (2n), not (1 ÷ 2)n.[1] For example, the manuscript submission instructions for the Physical Review journals state that multiplication is of higher precedence than division,[20] and this is also the convention observed in prominent physics textbooks such as the Course of Theoretical Physics by Landau and Lifshitz and the Feynman Lectures on Physics.[d]

Source:https://en.wikipedia.org/wiki/Order_of_operations


Using this logic, then the answer would be 1 as multiplication is done first


Regardless, things need to be standardized before a rocket explodes on lift off

Sorry I did read it but Wikipedia is relying upon people reading things then putting them on Wikipedia. So it's a secondary source. It does also refer to physics text books, yes, explaining what I was taught.
I do agree that things need to be standardised though I would hope that anyone working on a rocket and the like would use parentheses correctly to get rid of any ambiguous situations. Actually entering an equation such as the example in this thread should be something that people should be educated not to do.

Anything put on the internet is going to be a secondary source, according to your definition.

You'd have to go to a library and check out the physics books/journals to get the primary source, of which wikipedia cites...

Unless, of course, you'd consider going to the websites that wikipedia cites to be primary sources (?)...

Anyways, I don't intend to turn this thread into an argument about primary or secondary sources - smiles....

From my math-genius friend:
---

It goes way beyond just "whether Ubuntu's calculator app should be corrected to use PEMDAS" -- it absolutely should! -- but then, so should all the other multitude of calculator apps, firmware in actual physical pocket calculators, online calculators, etc., if they, too, get it wrong, which many of them clearly do. This is a disaster of epic proportions waiting to happen. Allow me to elucidate:

First, to establish my credentials for this forum: I am both a math nerd and a programmer of 40+ years' experience. I remember everything from every math or computer course I've ever taken, from the 1st grade in 1969 to grad school in the mid-to-late 2000s, and I continue to learn new things online almost every day. So, while I'm virtually certain of everything I'm going to say, I also leave room for the possibility, however slim I may consider it to be, that maybe, just maybe, something fundamental has changed in the last fifty years -- but the basics of arithmetic seem to me to be something that shouldn't change, shouldn't evolve over time -- they should remain rock solid forever. Otherwise the whole edifice of mathematics collapses.

So, now on to the matter at hand: the evaluation of the expression 48/8*(14-8), specifically as to "what's the right answer?" Some people insist it's 36, while others insist it's 1. One fellow on a different forum says it's ambiguous because the answer can be changed by adding another set of parentheses, viz: 48/(8*(14-8). Someone else dismisses the entire thing as a joke. But it's definitely not a joke: the Internet is full of confusion about it; there are actual physical pocket calculators some of which give one answer and some the other; and I consider it vitally important to at least try to get everybody "back on the same page again," as they were before pocket electronic calculators, let alone computers, came onto the consumer market in the mid-1970s.

Prior to calculators and computers, there was no argument: the rules some of us (or at least our children) were taught as PEMDAS or some such acronym, were the one-and-only standard, whether they were actually called PEMDAS or not: everybody was taught that you evaluate parenthesized expressions first, then exponential expressions, then multiplication, then division, then addition, and finally subtraction. (Some people have another name for it, which uses the term "brackets" instead of "parentheses," and they seem to omit the notion of exponentials altogether, but it's still the same rules.) By those standards, which had been established over literally hundreds of years, the expression under discussion evaluates thusly:

P: (14-8) = 6, and the expression becomes 48/8*6
E: there are no exponentials, so the expression doesn't change
M: 8*6 = 48, and the expression becomes 48/48
D: 48/48 = 1

and we're done. That answer, 1, is, was, and ever shall be, the right answer, according to hundreds of years of mathematics and mathematicians and the rules of PEMDAS.

When kernelhead first showed me his screenshot of the Ubuntu calculator delivering the value 36 for this expression, I was horrified. It was clear where it came from -- naive left-to-right evaluation respecting only the Parentheses part of operator precedence rules:

P: (14-8) = 6, and the expression becomes 48/8*6

Then, as though pressing one key at a time on a 1970s calculator,

4 - display would show 4
8 - display would show 48
/ - display would show 48
8 - display would show 8
* - display would show 6 because calculator performs 48/8 immediately
6 - display would show 6
= - display shows 36

Which is fine, as long as you recognize that by pressing the keys in that order you've naively performed the operations in the wrong order, which is to say you've calculated the expression (48/8)*(14-8), a.k.a. (48/8)*6, instead of what you were given. If you've evaluated the wrong expression, you cannot have done otherwise than to obtain the wrong answer!

To get the right answer on a naive left-to-right calculator, you, the human being, had to know the rules of arithmetic and realize that the original expression requires a different order of button-pressing:

4 - display shows 4
8 - display shows 48
/ - display shows 48
( - (display might show various things depending on calculator, but probably still 48)
8 - display shows 8
* - display shows 8
( - (display probably still shows 8)
1 - display shows 1
4 - display shows 14
- - display shows 14
8 - display shows 8
) - calculator evaluates inner parenthetical expression 14-8, so display shows 6
) - calculator evaluates outer parenthetical expression 8*6, so display shows 48
= - calculator finally performs the division entered before the first parenthesis, so, 48/48; display shows 1

Worse, for a good many years in the beginning, calculators didn't have parentheses. If an expression had parentheses, you had to do the part in parentheses first, write down the answer, and use that in a whole separate, second (or third, or...) calculation to get the final answer:

1 - display shows 1
4 - display shows 14
- - display shows 14
8 - display shows 8
= - calculator computes 14 - 8, so display shows 6, and you write it down.

8 - display shows 8
* - display shows 8
6 - display shows 6; (this value is the result you wrote down, above)
= - calculator computes 8 * 6, so display shows 48, and you write it down.

At this point it's clear that the final calculation is 48/48, which I hope most of you don't need a calculator to perform, but just for the sake of completeness:

4 - display shows 4
8 - display shows 48
/ - display shows 48
4 - display shows 4
8 - display shows 48
= - calculator computes 48 / 48, so display shows 1 and, again, this is the final, and correct, answer.

Don't take my word for it; you should be able to Google up any number of 1970s calculator owner's manuals, which often went into lengthy explanations of just how to do these sorts of calculations correctly.

Separating the calculation into these separate pieces is exactly what later calculators' parenthesis keys did, internally.

(As a math nerd, I myself had HP calculators, which used a whole other notation that required even more mental agility and rearrangement of terms: Reverse Polish Notation (RPN). Other kids would ask to borrow my calculator, I'd hand it to them, and after about ten seconds they'd hand it back because they couldn't find the = key, because there wasn't one. See, an expresson like 3 + 4 is written in what is known as "infix" notation: the operator comes between the operands (things to be operated upon). But other notations exist: prefix notation, in which the same expression is written as + 3 4 , and postfix notation, in which it is written as 3 4 +. On HP's RPN calculators, instead of an = key, there was an Enter key, which you pressed in order to "push" the displayed entry onto a stack; the arithmetic operations then popped their operands off the stack, operated on them, and left the result on the top of the stack. On the HP, the calculation we're considering here today would look like this:

4 - display shows 4; stack is empty
8 - display shows 48; stack is empty
Enter - display shows 48; a copy of the value 48 is pushed onto the stack
8 - display shows 8; value 48 is still on the stack, but invisible
Enter - display shows 8; a copy of the value 8 is pushed onto the stack, ahead of the 48 already there
1 - display shows 1; values 8 and 48 are still on the stack
4 - display shows 14; values 8 and 48 are still on the stack
Enter - display shows 14; a copy of the value 14 is pushed onto the stack, ahead of the 8 and 48 already there
8 - display shows 8; values 14, 8, and 48 are still on the stack
- - subtracts 8 (on the display) from 14 (first thing on the stack), placing 6 in the display, removing 14 from the stack, leaving 8 and 48 still on the stack
* - multiplies 6 (on the display) with 8 (first thing on the stack), placing 48 in the display, removing 8 from the stack, leaving 48 still on the stack
/[/B] - divides 48 (on the display) into 48 (first thing on the stack), placing 1 in the display, removing 48 from the stack, leaving the stack empty

Again, the right answer is 1.

Incidentally, this is also exactly how the programming language Forth, and the page-description language PostScript, operate.

But I digress.)

The problem with the Ubuntu calculator,and many others, isn't precisely that it "gives the wrong answer," but rather that it gives an answer that computer programmers have come to think of as right, when it is actually only "right" for computer programmers while they are actually programming. That's because programmers have spent the last 30 years working either in C, or in a language whose syntactic roots lie in the C tradition -- and the C Language Standard decreed, years ago, that expression evaluation in a C source statement would proceed strictly left-to-right, except for performing parenthesized expressions first (by recursively applying the same rules). Under that standard, a program statement such as

x = 48/8*(14-8)

will, should, and does, deliver the result 36.

The problem is that people confuse this result, which is indeed "in accordance with the rules of the programming language" with "the right answer," mathematically, which is a whole other thing. That's perfectly okay as long as the C rules remain buried in a program that the user never sees in that form, and the calculations do what they're supposed to do. Specifically, here today, I'm alarmed that this discrepancy has now been exposed to the user in calculator apps etc. -- and worse, that 36 is being promoted as the "right answer," which is absolutely untrue anywhere other than during the actual act of computer programming, and that the confusion represents a disaster waiting to happen.

We've raised, now, a generation or two of people out there (and in here today!) who don't even know they're wrong. If you believe 36 to be the right answer here today, you've made the very mistake our teachers warned us about, of "trusting the calculator," which in this case translates into "treating all arithmetic expressions as C or C-like source code" and calling that result "the right answer," which it isn't, anywhere other than in a line of program source code. I wouldn't want to have a tax accountant who did arithmetic your way, or who used a calculator, or calculator app, that did it your way! Jeez, imagine the uproar.

I won't be surprised to see this problem lead to tragedy someday, as this particular bit of ignorance and misconception gradually spreads through the engineering professions and starts to produce fatal errors in the designs of bridges, buildings, vehicles, spacecraft, etc. (I will try hard to get onto the Congressional committee investigating the disaster, so that the right one of you gets the blame.)

So, please, please, I beg you, programmers, please do everything in your power to disseminate clarity rather than obfuscation: at the very least, put a glaring, obnoxious, text banner in your calculator display, warning the user that "this app evaluates arithmetic expressions according to the rules of [language it's written in], not by the PEMDAS rules of proper arithmetic!" Better yet, instead of just letting your language interpret raw user input, I strongly urge you to implement (or find; I expect someone has already written) a proper PEMDAS-observing expression evaluator, that you put the user's input through in order to just plain give them the answer that is right in the everyday world, not just yours. Please.

dugan found an online text book.
I just mean that Wikipedia is, in effect, the same as this forum or the Ubuntu one and will be written from a certain perspective.
The OP states a mathematician says PEMDAC stands but doesn't state how qualified they are (not that we can prove that but, still) nor where they got this information. For all we know the mathematician is a physicist.

In the post I just made, the qualifications/credentials of my friend whose very good at math.

I don't see any mention of a degree or doctorate? I don't see any mention of where he got these rules from.
This is my issue here - I want to believe in some ways because that's how I was taught but if it's wrong then it's wrong. Similarly if it has changed I'd be interested. Might never happen but if I'm trying to help my nice or nephew with homework (or my own child but that would be even more doubtful) it might be good to know. Not to mention just being curious.

Again: by your friend's logic, addition and subtraction would have different precedences as well. They don't. They're associative. So your friend's entire long post is wrong.

Python does in the parenthesis first, does not do multiplication before division unless made to.
Edit:
Same with bash

So I guess it depends on which source you believe is right in mathematics - programming languages or the manuscript submission instructions for the Physical Review journals, prominent physics textbooks such as the Course of Theoretical Physics by Landau and Lifshitz and the Feynman Lectures on Physics.

I think most of us know who Richard Feynman was - I suppose he didn't win the Nobel Prize in Physics by using the wrong order of operations for math...

IMHO 48/8*(14-8) isn't the same as 48/8(14-8) which the calculator treats as the same, therefore this discussion.

Math friend typing directly:

I hold a BS in Computer Science (Ball State University, 1988), plus additional studies in CS at the University of Rochester in 1984 and 85, and in Electrical Engineering at Rensselaer Polytechnic Institute (RPI), 1981-84. I completed all but the final paper of a Master's degree in CS at SUNY Institute of Technology (known as SUNYIT at the time) from 2007 to 2015. I learned mathematics in grade school, middle school, and high school, won first place in my county math contest in the 7th grade, and participated successfully in my high school's Math League team. I took Algebra in 8th grade, and in high school I took Geometry and Calculus, plus other things I'd have to look up the names of. I got 100% on the AP Calculus and AP Physics final exams and others, and was able to enter RPI as almost a sophomore. At RPI I took Linear Algebra, Vector Algebra/Mechanics, Boolean logic and digital circuit design, and Advanced Calculus, to name just the math-heavy stuff. I love math and have continued to read and learn for the forty-ish years since I was last a student in a "math class" per se. I collect and read math (especially Calculus, Linear Algebra, and Complex Variables) textbooks, and do math (including those same areas) for fun and in hobbyist computer programming. I can also safely be assumed to have picked up a few things on the job, in 25+ years as a Software Engineer in both commercial and scientific fields... I also tend to hang around, online and in person, with mathematicians, scientists, engineers, etc. I can bring some of them in on this, if you want to *really* take a browbeating.

As for PEMDAS, I don't remember learning it by that name or the Aunt Sally business; somewhere along the line, I was just-plain taught the rules of arithmetic evaluation, so log ago that they simply feel like a fundamental part of my very being. I first encountered the term PEMDAS, specifically, when my daughter was taught it in Community College, around 2008. But I recognized it immediately.

It's certainly possible that whoever makes the rules, sets the standards, and decides what shall be taught, could decide to change PEMDAS, or replace it with something else -- but that would be a disaster, as it would render all previous math writings incomprehensible to all future students because they'd be operating with a different set of rules for interpreting what's written. I would be deeply mistrustful of anyone who tried to propose or promote such a thing, and I know such people are out there.

Neither I, nor PEMDAS, claims that "addition and subtraction have different precedence" -- they're simply both included "for the sake of completeness," as far as I'm concerned. Certainly a six-letter mnemonic isn't going to capture the entire process of expression evaluation; as I tried to emphasize in my earlier remarks, you have to understand what you're doing! There's no substitute for that. PEMDAS is merely supposed to cue/remind you of the order of application of the full rule set.

I also never said that, once PEMDAS is accounted for, run-on strings of additions-and-subtractions were to be evaluated in any particular order; if you'd like me to clarify, then "all else being equal, e.g. if an expression involves only addition and subtraction, you can perform them in any order, since you get the same result in any case." Take note, though, that the same is not true of multiplication and division: the whole difficulty in the case that started all this is that by PEMDAS rules you do the multiplication of 8*6 first, then the division of 48 by the result, "because PEMDAS," whereas by C-like, purely left-to-right rules you encounter, thus perform, the division first and then the multiplication (and with no extra set of parentheses to force the multiplication to happen first as a consequence of PEMDAS). Only one of those orders-of-operation is how arithmetic per se is to be done, and it's the former, not the latter.

If I had to guess -- and I do! -- the latter was most likely a design choice in the early C language definition to save Kernighan and Ritchie the time and effort of having to write a more complex PEMDAS expression parser and code generator -- but if they'd known the consequences that choice would engender, they would probably have chosen to take the time and go to the effort. Failing that, I would like to have seen somebody, at some point between then and now, draw a line in the sand and say, "No more propagation of non-PEMDAS expression evaluation! This new language (or version of the old language) will look-and-feel like C, but will evaluate expressions according to the proper rules of arithmetic to avoid confusion in the future when the early history of this subject is forgotten." That's what I would have done, certainly. Because, now, the early history has been forgotten, and confusion reigns. You should all be as alarmed as I am.