This being a forum based on Wolfram technologies, it's not cheating to avail oneself of the software.

Quantity[4, "dozen"]/Quantity[2, "dozen"]

(* Out[2]= 2 *)

My point is that this should absolutely not be written as 4(12)/2(12). Once one posits "four dozen" of this and "two dozen" of that, these are implicitly grouped (in your terms, "combined quantities"), that is to say, as (4x12) and (2x12). So ungrouping them is kinda a bad idea.

I see the claim "There is nothing confusing or ambiguous about the expression 6 ÷ 2(1+2)..." I would raise the question of whether one should treat any differently the expression 6/2(1+2). If the answer is "no" then I'm hard-pressed to buy that; that expression must evaluate to 9 (I mean, how do you justify first multiplying the 2 by the (1+2). That would be operating from the right, which is to say wrong, end of the expression. I do not think this is taught anywhere.) And i the answer is "yes" then I have to ask why we treat one division sign differently from another. (The answer to that is "we don't".)

Getting back to PEMDAS, the rule is that equal precedence goes left to right; this is taught in schools I believe. And it's the dominant convention nowadays. Not something I would choose to fight, and, in particular, I'd not want to teach algebra in a way that ignores it (even if it is not explicitly stated).

I make no claim about what's taught in schools. I suspect what you describe is as it was taught even when I took algebra. From a teaching perspective maybe that makes sense, at least if the obelus is regarded as strictly a binary operator.

Here is the catch though. We now have students using calculators and computers in math and also using them post-school in their careers. Computer languages need to follow a grammar, and that grammar needs to be unambiguous. So PEDMAS is back in the picture. I guess one has to choose which convention makes the most sense based on where the question arises (e.g. in an algebra classroom, or in an automated computation).

Best in my view would be to retain the two-dimensional division operation for classroom purposes. I think that handles the ambiguity without sacrificing the integrity (such as it may be) of monomials.

I wonder how many calculators with symbolic capabilities follow this convention.

This one does not.

https://web2.0calc.com

Likewise:

https://mathsolver.microsoft.com/en/solve-problem/a%2Bb%60divc

https://www.mathway.com/Algebra

https://www.wolframalpha.com/input/?i=%5B%2F%2Fmath%3Aa%2Bb%2Fc%3Dd%2F%2F%5D

and Google's online calculator.

This one gives choices and explanations for ordering operations. https://www.calculatorsoup.com/calculators/math/math-equation-solver.php

These next have the courtesy of rewriting as you go, so at least you know how they parse your input (they all require parens to get the effect shown in the pedagogy sites noted earlier), that is to say, they support PEDMAS at least to the limited extent that I checked.

https://www.geogebra.org/scientific?lang=en

https://www.mathpapa.com/algebra-calculator.html

https://www.polymathlove.com/polymonials/midpoint-of-a-line/symbolic-equation-solving.html

https://classcalc.com/scientific-calculator

https://www.desmos.com/scientific

https://www.symbolab.com/solver/equation-calculator/x%2By%5Cdiv3?or=input

I wonder how students reconcile this. Maybe they just get used to the difference and expect one convention in class and another online and/or in computer programs.

That would be nearly every online calculator and I suspect every symbolic programming language. Except those languages are correct, insofar as they require and enforce an unambiguous grammar. Which you will not get from the rules that apply to a quotient of two expressions (I avoid use of "monomials" because it's not clear that expressions will always be monomials).

Before you insult the people who program those calculators (people like myself), maybe consider the possibility that we are familiar with requirements of unambiguous grammars, and that these requirements go well beyond infix operators from simple arithmetic expressions. Also bear in mind that these operators, division among them, are (often) not restricted to binary. Hence you'll need to be certain that whatever convention you apply generalizes to three or more arguments.

For what it's worth, I did not miss those days in class (granted, they may have been different years). Yes, division=fraction. But that alone does not tell a parser where to end a subexpression, one needs more rules for that.

I guess another point to consider is the extent to which it's worth fighting against prevailing technology. These calculators and programming languages are not going to change just to accommodate the particular interpretation you are providing. It would be good if students know to plan accordingly.

If you want, I can show you other online calculators which correctly interpret monomial division as a fraction (i.e. the term to the left of the obelus is the numerator & the term to the right is the denominator. One cannot generalize how the programming of calculators is set up across the board. The quality & accuracy of the programs vary widely based on the skill & understanding of the individual programmer.

A monomial does not require parentheses surrounding it -- see all those examples taken from teaching websites, telling young math students to "Rewrite as a fraction," when the original expression was written with an obelus, without parentheses around the monomial divisor. The fraction then shown in those lessons for young math students was the whole term to the right of the obelus was the entire denominator of the top-and-bottom fraction.

There is absolutely nothing confusing or ambiguous about monomial division expressions. There is only ever one correct answer. 6÷2(1+2)=1 because it's 2a÷2a when a=(1+2) ; 8÷2(2+2)=1 because it's 2b÷2b when b=(2+2) ; 48÷2(9+3)=2, because it's 4x÷2x=2 when "rewriting as a fraction" with the whole monomial term to the right of the obelus being the denominator. The only time parentheses are necessary around a monomial is when there is more than one division symbol in the expression, to indicate the correct order of the divisions (i.e. to show where the "main" denominator is).

Whether an expression is written with a vinculum (fraction bar), a solidus (slash) or obelus (division sign), they have the same quotient since they are all 100% synonymous with one another (see 5th grade math). Division by a monomial is all very simple & straightforward, once the rules are clearly understood.

[Eric, I thought I was replying to the one above yours, so apologies if it is grouped like it’s intended for you.]

Only ever one correct answer…for a given convention. If the intent here is to troll for a flame war, this isn’t the right forum. If the intent is to insist that a particular convention is sacrosanct, again it’s the wrong forum. If the intent is to discuss relative advantages of one or another implicit grouping convention, I’m not seeing anything to support the notion that a certain precollege classroom convention should extend to universal usage. I do know of reasons to not do that, but it seems they get ignored (recall mention of associating multiplication operators from the left, something this 9th grade convention violates). The world of mathematical and scientific computation goes past high school, and computer languages have their own needs. Different houses, so to speak, with different rules.

I’m not too worried about what get’s taught in 9th grade math. I am getting a bit curious about what’s happening in math ed though. Should you respond with something of new interest (that is, not more on-line math ed and not more about the proper care and feeding of monomials) then I will take a look. Otherwise I think this has run its course.

No, I have not been "unwilling to accept the arbitrariness of conventions--being so self-referential that you can't even conceive that your assumptions aren't universal." I have shown voluminous examples, from all over the world, on a myriad of math teaching websites, of how monomial division is executed when written with an obelus (division sign). On website after website, the monomial division expression is shown as a top-and-bottom fraction, with the monomial to the right of the division sign as the WHOLE denominator.

If you want to keep insisting that converting a monomial division statement to a top-and-bottom fraction is NOT regarded as the standard convention across the board, please show some hard evidence of how students & teachers across the world are teaching how to execute monomial division such as 4a÷2a, given that "a" does not equal zero. Please provide links to multiple websites which instruct, step by step, how to execute that division by a monomial which is originally written with an obelus & no parentheses around the term to the right of the obelus. Let's see it.

Yes, exactly. Thank you.

Eric, I was thinking the same thing. We're maybe being... botted. (Is that a word? I should be.) It seems the response pattern never changes, the points that get ignored never change, and those that recur rise from the dead faster than zombies.

Essentially every programming language, whether it uses a slash or other symbol to denote infix division, parses as I stated. This has nothing to do with how the math is taught, and everything to do with the programming language world having converged to a (mostly) common standard. Students who expect different outcomes usually learn to adjust as well, especially CS majors. It's sort of a necessity at that level.

"Isn't is true that 24/12 can also be written as 24÷12 because both the slash & the division sign mean "divided by"?"

We've strayed way out of scope for this forum. The answer is yes but that has nothing to do with parsing arithmetic expressions which in turn only tangentially intersects Wolfram Community.

"I look forward to that complete contradiction being explained as something other than the programmer's lack of understanding of the basic concepts behind the acknowledged methodology, used worldwide, to execute division by a monomial."

The language committees know what they're doing; that has nothing to do with any particular programmer's understanding. The programmers who write the language compilers know how to parse to meet the design specs (I can say this with assurance, having been one myself prior to math grad school).

If you don't like the outcome of this seemingly collective decision then you'll need to plan accordingly (read: only use calculators that use the precedence you like, and avoid all serious programming languages). I can pretty much guarantee that the former students who go on to higher math will have sorted this out for themselves, and will never look back. Should you encounter one of yours you might wish to ask about this. Especially if said former student has experience as a programmer.

"Some [...] programmers"? No. Pretty much all of us, amounting to tens (hundreds?) of thousands scattered across all inhabited parts of the globe. You can (and do) rail about his. Given your apparent confusion it might be wiser to pause and ask why this particular standard has come into use.

I have yet to see the point about claims ad infinitum of this notation equals that so that equals this notation equals the other, to how computer languages handle infix expression parsing. Expressions encountered might be the same but the parsing/grouping claimed for algebra class is different from what's done by language compilers and interpreters. If that's a fundamental obstacle for you, avoid the programming languages.

Because some computer language writers & calculator programmers apparently only have a limited grasp of the underlying concepts of monomial division

Okay, so you're not only saying that there is only one acceptable convention for order of operations for use in general conversation, but you're adding that no community is free to choose for its own use within its own domain a different convention that they believe works better for them in their domain. The only possible way that a community could adopt for its own use a different convention is if that community is ignorant. Wow. Just wow. Would love to see your reaction to non-euclidean geometry.

No real discrepancy there. The natural language interpreter is making a guess as to intent. It misses your intent in the first instance. Possibly that's a shortcoming in the guessing semantics, or maybe it was intended based on the sentence structure. My guess is the former; you could send feedback about it if you like.

My guess is that the problem is in the natural language processing part, and that it produces "raw" computational input that is not properly parenthesized. Running the command below in WL seems to bear out this supposition.

In[204]:= WolframAlpha["2a divided by 2a", {{"Input", 1}, "Plaintext"}]

Out[204]= "2\[Times]a/2 a"

I suspect it will be fixed, though I cannot guarantee that.

It all depends on what they call the precedence of the operators. For Mathematica (Wolfram Language) the Divide has a higher precedence than Times. So it will first do divisions then multiplications:

Precedence[Divide]
Precedence[Times]
470
400

But in other cases you also have to look at how it groups:

6/2/3

could be 6/(2/3) or (6/2)/3, giving different answers.

have a look here:

https://reference.wolfram.com/language/tutorial/OperatorInputForms.html

To sum up: the author of that equation is just sloppy; you have to assume something in order to solve it, and depending on the conventions... so therefore always add extra parenthesis to rules out those cases...

Thank you for your response Gianluca,

For my own edification, what context clues would there be to solve the equation any other way? Which interpretation makes the most sense in this context? 9 or 1? Would a word problem make this easier to understand as well?

Also I very much appreciate any responses in this thread--All of us have access to the same Wikipedia and websites that have greater detail...however for my end users who are obstinate about unreliable sources I wanted to come to the most credible place.

That is a classic. The problem is that there is no universal agreement on how to parse expressions with a mix of multiplications and divisions, or with more than one division. Does 1/2a mean 1/(2b) or (1/2)a? It is a matter of convention. Mathematica treats it as (1/2)a, but you may find books where it is meant as 1/(2a), perhaps because this way you save typing parentheses. Usually the ambiguity can be decided from the context, as only one interpretation makes sense. I teach my students to avoid expressions such as a/b/c and always write parentheses to make sure they are not misunderstood. There is a Wikipedia article on the "Order of operations". The calculation 6 ÷ 2(1+2) = 6 ÷ 2 + 4 = 7 is a gross mistake in my view.