What're the orders for equation expressing?
When doing an equation in programming or real calculations, equation expression takes in a specific order. In a single equation, I use the PEMDAS/GEMDAS order, which goes:
- Perform all operations that are grouped up by parentheses first before non-grouped ones; the more it's grouped will be performed first
- In the (grouped) equation, any values to be exponentiated will be exponentiated first
- If multiplication goes first before division in the (grouped) equation, multiply the values to be multiplied, and vice versa
- If addition goes first before subtraction in the (grouped) equation, add the values to be added, and vice versa
I want to explore further though, see if there are any other orders out there so I can figure how I can solve other complex equations, like the modulo, which is not in PEMDAS for all I know.
Question: Are there any other equation expression orders that are considered valid by professional mathematicians?
2 answers
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| General Sebast1an | (no comment) | Jul 12, 2022 at 10:49 |
This question contains a lot of confusion. First, an equation is something like $f(x) = g(x)$ (i.e. there's an equality sign). Solving an equation means finding (all) values for the free variables such that both sides become equal. In the above example, this would mean finding values for $x$ such that $f(x) = g(x)$.
PEMDAS is often described as a mnemonic for "order of operations" or "order of evaluation" meaning it tells you which subexpressions need to be evaluated first, but this is incorrect. Before getting to that, it probably helps to define "expression" and "evaluating an expression". Informally[1], an expression (or term) is some (well-formed) combination of operations, literals such as numbers, and variables. Which operations, literals, and variables are allowed depends on the type of expression it is, e.g. an arithmetic expression might not allow any variables and only allow +, -, *, / as operations. Semantically, an expression has a (typically numeric) value. (By contrast, an equation doesn't have a value but is rather something that holds or doesn't hold.[2]) Evaluating an expression usually means reducing it to some normalized, "simplified" form[3]. For example, $3^2$ is an expression and evaluating it would produce the number $9$.
Returning to PEMDAS, the first thing to note is this is only for expressions having a certain set of operations (exponentiation, multiplication, division, addition, and subtraction). It is not a general rule for all types of expressions. Regardless, PEMDAS doesn't have anything directly to do with evaluation and is instead about precedence. To put it one way, PEMDAS and precedence in general are about telling us where to insert parentheses in expressions.[4] Exponentiation being higher precedence than addition means 3^2+5 corresponds to (3^2)+5 and not 3^(2+5), and that's it. It says nothing about what order things are evaluated in and doesn't involve or require evaluation at all. Instead, it lets us know what the subexpressions are. In mathematics (as opposed to programming), we can evaluate subexpressions in any order. In 3^2+5 using the precedence rules that PEMDAS refers to 3^2 is a subexpression, 2+5 is not. Indeed, "what are the subexpressions of this expression" is a question that PEMDAS helps answer but doesn't involve evaluation.
It is rare but not unheard of to use different precedences for the operations PEMDAS refers to. This is just a matter of notation and is generally not considered a mathematically interesting alternative choice any more than using a different natural language would be. For operations, like modulus, that PEMDAS doesn't cover, their precedences will either be specified, or they won't be used in ambiguous ways, e.g. they will always have parentheses to disambiguate. Admittedly, authors aren't always that clear about these precedences, and sometimes they aren't specified so much as implied as one precedence leads to expressions that make sense and a different precedence leads to nonsense. For example, it is intuitively obvious that = has lower precedence than arithmetic operations as 3+(4=7) makes no sense, while (3+4)=7 makes sense.
-
See this grammar for a formal description of algebraic expression. That page also gives links to more formal definitions of the various words I'm only informally defining here. ↩︎
-
That said, we can sometimes view equations as expressions that are Boolean-valued. Most of the time, though, there is a formal distinction between terms/expressions which have values in some domain, and formulas which can be either true or false. ↩︎
-
Evaluation may also be a matter of interpreting an expression into some semantic domain. ↩︎
-
To put it a different way, it is information needed to produce a unique (abstract) syntax tree from an expression represented as a string. When formally manipulating expressions, it usually makes more sense to think in terms of these trees and not strings of characters. ↩︎
Another aspect of operation precedence which Derek's otherwise excellent answer doesn't cover is operator associativity.
Implicit in the PEMDAS convention is the idea that the arithmetic operators are left-associative, meaning that they should be grouped from left to right when a subexpression consists of several operators in sequence that are the same (or otherwise have equal precedence): \(2 - 5 - 3\) is grouped as \((2 - 5) - 3\); \(60 \div 5 \div 4\) is grouped as \((60 \div 5) \div 4\). Sometimes, the convention for an operator is that it is right-associative. For example, the arrows in Knuth's up-arrow notation for hyperoperations are usually assumed to be right-associative: \(3 \uparrow 4 \uparrow 5\) is assumed to mean \(3 \uparrow (4 \uparrow 5)\).
Of course, if an operation has the associative property, as \(+\) and \(\times\) do, that means there's no need to declare the operator as left- or right-associative. The expression will evaluate to the same result with either grouping.
0 comment threads
1 comment thread