I've never found it to be an issue with math. Unary minus > powers > multiplication/division > addition/subtraction.
I have seen differences in the precedence of logical operators between languages (and > or but what happens when you have both math and logic in the same statement isn't entirely consistent) and always use parenthesis in those cases--although these days if Resharper says it's redundant I let it remove them.
Me too! So far I have seen four actual bugs in large numerical code bases that were caused by overlooking operator precedence. I expect to see more in the years to come.
I think that precedence of '*' over '+' is acceptable (as everyone knows it instinctively) but I would love a way to require parenthesis for everything else.
2. Evaluate division and multiplication operators, left to right
e.g. 1 / 2 * 3 / 4 = (1/2) * 3/4 = ((1/2)*3)/4
3. Evaluate addition and subtraction operators, left to right
Your issue seems to stem from the left-to-right concept (in order in which operators are encountered as you read, left-to-right).
Your example of 6/2x to me is clearly (6/2)x. What is 1/2x ? In my experience, textbook authors/professors/math teachers tend to be disambiguous and either use the horizontal line for clarity or use parenthesis.
I attended public schools in Ontario, Canada if it makes any difference.
Edit: Oh yeah, also I have never felt that implicit operators would take precedence. Interesting!
For language-specific operators I could understand ... but to me, the cognitive load of the parentheses is worse than having to think for a moment about this particular set of operators which have the same precedence in every language I've used (and the arithmetic operators which I've had to know the order of since early grade school).
Smalltalk also has different precedence rules. Assignment is highest, followed by unary ops, binary ops, then keyword messages. In some cases, this results in expressions evaluating left to right.
This is often the biggest complaint from outsiders. But it's easily solved by including parenthesis now and then. In 10 years of doing Smalltalk, I've never encountered a situation where this is ever an issue. I've never encountered a but caused by math expression precedence. Newb Smalltalkers might make the mistake, but they generally correct it in the next second. So much for the first impression of programmers who are unfamiliar with the language.
In 10 years of Smalltalk, I've also never encountered a situation where Smalltalk execution was slow -- it was always poorly designed (low-latency favoring in a high-latency environment) database IO. If anything, I've always been impressed with how fast the commercial VMs are.
My point: the "popular notions" about programming languages are often as misleading as urban legends.
In my experience you don't use nested arithmetic often enough to make it annoying. Most arithmetic in computing is basically `count := count + 1`?
What is more annoying to me is looking at an expression that mixes arithmetic and logical/comparison operators and mentally trying to recover the parentheses. Because precedence is not just PEMDAS: it involves all binary operators in the language, including logical and bitwise ones.
The problem is to prioritise addition over subtraction and multiplication over division rather than assigning them equal priorities and evaluating the expression left-to-right. In German, there is no ‘PEMDAS’ but only ‘Punkt vor Strich’ (‘Dots before dashes’?), i.e. multiplication/division (·,:) before addition/subtraction (+,-). Parentheses obviously still take precedence.
Well, is the implied multiplication technically part of the parenthesis, though? I've always been taught the stuff inside the parenthesis takes precedence, but outside is irrelevant because it's not technically "part" of the parenthesis statement.
It's like how programming works:
6 / 2 * add(1, 2)
This would obviously evaluate to 9, because the "add" function would simply return a value and the rest of the statement would be evaluated from left to right. In this case, the first 2 is not related to the "add" function in any way.
> I am unaware of how it handles math expressions in particular.
It does not automatically do order of operations. You have to explicitly use parentheses, as you say. However methods in Smalltalk tend to be quite short do to the nature of the system so it tends to not be as messy as one might expect.
My programming teacher told me: "operator precedence is complicated, always use parenthesis if you have multiple operators in a single expression". I simply do that, and nobody complained so far :)
but isn’t implied operator precedence and using parentheses to group and control order of operations one of the things people often find confusing in mathematics, despite it being familiar?
Annoyingly, SmallTalk actually does this, so they got there first. The reason is that operators are just methods (and numbers are objects) and so arithmetic dispatches left to right unless parens are used, ala (1.+(2)).*(3)
Well, order of precedence rules are much more complex in programming languages, and are not the same across languages. Mixing math with logic and bitwise operators without explicit parens is a classic "newbie" mistake.
Indeed. I just never really internalized all the operator precedence in C/C++ so I never write code like `a + b >> c`; I always add parenthesis when mixing arithmetic and bit operations.
Honestly, most of the time I think we would be better off without operator precedence. It just adds another thing you need to keep in your head when reading code.
Unfortunately, nearly everyone -- even non-programmers -- learned the operator precedence for arithmetic operators, which means they might be confused if those operators in a language didn't use it.
I've never seen it be buggy, but it will often remove unnecessary parens. For example: (a * b) + (x * y) becomes a * b + x * y.
This the same code, but I often use parens for semantic grouping or to be 110% sure the operator precedence is correct for a particular formula. It's not a dealbreaker, but it does remove some of the meaning I was trying to imbue on the code.
> Unlike in most other languages, operators always have the same precedence and expressions are evaluated in right-associative order. That is, unary operators apply to everything to the right, and binary operators apply to the operand immediately to the left and to everything to the right. Thus, 34+5 is 27 (it groups as 3(4+5))
I have seen differences in the precedence of logical operators between languages (and > or but what happens when you have both math and logic in the same statement isn't entirely consistent) and always use parenthesis in those cases--although these days if Resharper says it's redundant I let it remove them.
reply