Re: Operator precedence and code readability

Left-Associativity is only defined for one operator X: a X b X c = (a X b) X c. This does not define anything for two different operators (* and /).
The problem does not exist for subtraction, because you could always write (a - b - c) as a + (-b) + (-c) and use the commutativity of + to reorder any way you want.
In theory you could also do something similar with a / b writing it as a * (1/b), but this implies a certain kind of reading of / that can be disputed.

In the meantime I found some more interesting material:
The rules taught in Math classes seem to depend on time and teaching language:
English math classes seem to teach Mnemonics, and sometimes (but not always) mention left to right.
Translating another rule: "dot before dash" (meaning dot: . and : before + and - ). Thich does not make it any easier if you write division with / instead of : Here left to right is usually not mentioned.
According to older textbooks and some math teachers up to at least the 1970s/80s: Use ÷ always after . But not all people who learned math in the 80s have died yet ;-)
Newer textbooks don't use the ÷ because math typesetting has significantly improved and fraction lines are used. So there is no need for a "left to right" rule for divisions here.
I found a (non-englisch) math forum discussion on "is there a left to right rule" that did not come to a consens.
I had a link with an example for an _expression_ where different people came up with different results already in my previous post.
Some (and I tend to agree here) consider these cases as undefined and malformed (if used outside a programming language as a context defining these rules).

Anyway: The original question is, do additional parentheses make the equation clearer.
And after spending more time than I initially planned to take a closer look, I'm now even more convinced to recommend parentheses for combinations of * and /

On Wed, Jan 13, 2021 at 11:23 PM Philippe Verdy <verdyp@gmail.com> wrote:

maths define the concept of "left associativity' (which is not the same as the full "associativity" defined for addition or multiplication). No need to refer to execution, only associativity matters and defines clearly where parentheses are not needed. But substraction, division, exponentiation are not fully associative: they all are left-associative only and this is sufficient for our purpose, so that any grouping of operands of binary operations, when there are more than 2 will require parentheses if the grouping is not using the left-associativity.

So
1*2*3 == (1*2)*3 == 1*(2*3) : full associativity, true in maths, not necessarily true in programming languages for all operand values (e.g. with float/double types, because of intermediate roundings)
1/2/3 = (1/2)/3 != 1/(2/3) == 3/2 : left-associativity only

Lua respects this... except for exponentiation where it defaults to right-associativity, which is quite uncommon (if we note it with the "^" operator on formulas written on a single baseline, like most other languages do when having a power operator like "^" or "**"; this excludes C/C++ and Java that don't have them but require using a functional "pow(x, y)" notation).

But it would be more natural if we use superscripts and we "stack" them at different vertical levels: when we don't stack the superscripts, maths formula require parentheses for the left-associativity. However Lua does not support superscript notations.

Le mer. 13 janv. 2021 à 20:40, bel <bel2125@gmail.com> a écrit :

> Yes, "a/b/c/d" is not a valid complex fraction, so an engineer should not try to interpret it this way.

To come back to the original topic, a recommendation for "when to put parentheses for code readability", I see three options:

a) have a list of people who are "allowed to interpret" and "not allowed to interpet"
b) always have a table of operator precedence at hand, or even type it in the comment next to the code
c) use parentheses at everything that could be mis-interpreted

I will definitely go for option c)

d) Give everybody a brief Lua programming introduction, where you do not assume these things are obvious

... there might be even better options, of course

> But "a÷b÷c÷d" is well defined, because division and multiplication are executed from left to right, every schoolkid knows it.

After some investigation, I have to disagree.
You might find this article interesting: https://math.berkeley.edu/~gbergman/misc/numbers/ord_ops.html
Apparently I'm not the only one who encountered this ambiguity.

Also (my) algebra books define commutativity, associativity, distributivity ... but never "left to right execution".
I NEVER heard of a left to right execution rule in math (only in programming), not at school, not at university.
I am not aware of any university grade algebra book (for mathematics students ... not programming books) that defines "left to right execution order".

I mean a book on fundamental algebra, not "this is correct because a scientific calculation program calculates it this way" because this would be circular reasoning.
Could you name a reference here?

On Wed, Jan 13, 2021 at 11:48 AM Egor Skriptunoff <egor.skriptunoff@gmail.com> wrote:
On Wed, Jan 13, 2021 at 12:21 PM bel wrote:
Wikipedia (https://en.wikipedia.org/wiki/Fraction#Complex_and_compound_fractions):
"So 5/10/20/40 is not a valid mathematical _expression_, because of multiple possible interpretation."

Yes, "a/b/c/d" is not a valid complex fraction, so an engineer should not try to interpret it this way.
But "a÷b÷c÷d" is well defined, because division and multiplication are executed from left to right, every schoolkid knows it.