# Why do we need/use operator precedence for Arithmetic operators?

Why do we use operator precedence rule for Arithmatic operators? Can't we simply just do the operation in a linear manner from left to right or vice-versa and deal with the operator that comes first. For e.g. 2+3*4 = (2+3)*4 , if we do the operation from left to right.

My guess why we might do it is that, since * and / (divide and multiply) are complicated and gets even more complicated if the operands are larger, whereas + and - (plus and subtract) are simple operations.

• It’s a matter of pure convention. There’s nothing beyond that. – Yuval Filmus Jan 6 at 18:27
• I feel this a matter of mathematical notation. I do not feel a CS angle beyond I am not particular about notations equivalent to the familiar one, and don't want to consider any that aren't. – greybeard Jan 6 at 21:28
• I would add to "pure convention" and to Aaron Rotenberg's answer that these are conventions that are similar or compatible with to those that many people are used to using with mathematical notation outside of programming. It's unlikely that someone would guess that x + y ** z means (x + y)**z, because no one would interpret $x+y^z$ as $(x+y)^z$. (However, since I don't like to go and look up the convention for whatever language I am using that week, I tend to throw in parentheses everywhere, which is OK because I usually work alone and one of my favorite languages is Lisp.) – Mars Jan 7 at 1:04

Rules for operator precedence beyond the basic arithmetic and relational ($$=$$, $$\leq$$, etc.) operators are domain-specific, and authors of papers occasionally have to specify the convention they are using in their notation section. Again, the purpose of having such rules is to improve communication in situations where specifying a convention that the reader has to remember is better than writing parentheses everywhere.
• With OP's proposed left-associative single-precedence notation you can write parenthesis-free polynomials: a*x+b*x+c*x…+d. Here the polynomial coefficients are a, b, c, …, d. That's arguably more straight-forward and certainly computationally more efficient than the way you are thinking about. – rici Jan 6 at 20:27