I wrote a (very long) blog post about those viral math problems and am looking for feedback, especially from people who are not convinced that the problem is ambiguous.
It's about a 30min read so thank you in advance if you really take the time to read it, but I think it's worth it if you joined such discussions in the past, but I'm probably biased because I wrote it :)
My apologies, I wasn’t trying to spar with you friend, just trying to understand why a/b*c wouldn’t also be considered ambiguous, particularly since an author could have written a*c/b and removed any doubt.
In your blog post you also quoted ISO
You seemed to speak rather definitively that it’s only ambiguous when combined with implicit multiplication.
I agree that almost all calculators and programming languages will interpret consecutive explicit multiplications and divisions with left-to-right precedence.
But as far as I’m aware no such LTR rule has global agreement in mathematics, I was curious if you found something in your research that says otherwise.
It depends on what you mean by global agreement as there is no single source of truth but the left-to-right rule is pretty much default for multiplications/divisions and additions/subtractions. If you however have inline power notations with "^" symbol they are evaluated right-to-left. There are exceptions but those are typically well known in the industry. For example MathCad also evaluates powers from left to right, which is fairly untypical.
It's not wrong if you make clear what you are doing. You can for example in a diagram call the axis a and b, not really wrong but pretty untypical if everybody else uses x and y, so you should have at least good reasons when doing it differently.
I would be particularly interested if you found something in a mathematical style guide that recommended an expression like
( a / b ) * c
Should be re-written as
a / b * c
Generally speaking, style guides advise rewriting equations for maximum clarity. Which usually includes a guideline of removing parentheses when their existence isn’t needed to clarify intent.
I believe, and I’m particularly interested to see if you found evidence that my understanding is incorrect, that the LTR convention used by calculators and computer programming languages today exists because a deterministic interpretation is a requirement or the hardware, not because any such convention existed prior to that or has been officially codified one way or the other by any mathematics bodies.
So like, forget division for a sec…
In a mathematics paper, you usually wouldn’t write:
(a + (b + c)) + d
You’d write:
a + b + c + d
(Except perhaps if in your paper the parentheses made it easier to follow how you got to that equation.)
Because in mathematics, it will never matter which order you do additions in, so you should drop the parentheses to improve clarity.
On a computer or a calculator though you might get a different result for those two equations like if a+b overflows your accumulator and c is a negative number, or when these are floating points values with significantly different magnitudes.
I believe english speaking engineers just adopted LTR as the convention for how to interpret it since they had to do something, and the english language is a LTR language. I don’t believe that convention exists outside of the context of computing.
The Wolfram quote and ISO quote in particular that you have in your post imply that an inline division followed by an explicit multiplication is ambiguous as to if it should be interpreted as a compound fraction.
If that’s correct, then it would be the inline division that makes it ambiguous, not the implicit multiplication that makes it ambiguous.
If there’s some source from before computers, or outside of the context of computers forcing a decision. Then your assertion that it is the implicit multiplication causes the ambiguity is correct.
I’m not trying to prove you’re wrong, I’m just genuinely curious which it is. And if you found evidence one way or the other.
Regarding the parenthesis the C# static code analyzer can be set to remove unnecessary parentheses.
https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/style-rules/ide0047-ide0048
IDE0047 is the static analyzer rule for "Remove unnecessary parentheses"
The default for those rules is to enforce parentheses on binary operations (because most people aren't as familiar with the binary operator priorities as they are with regular math operator priorities) and remove unnecessary ones in other mathematical expressions.
Besides that I can't remember that I saw a standard that states to only use parentheses if needed but I think it's reasonable ro assume that most people would do that anyway. Writing ((((5+3)))*2) is obviously stupid even though I can't think of any style guide that would explicitly state not doing that.
What many style guides actually state is to use proper fractions (horizontal bar) where ever possible.
Regarding the ambiguity with the implicit multiplication and division. The division is indeed required to make it ambiguous but actually only some kind of trigger
Let's take 6(1+2)/2. Even though the priorities with weak and strong juxtaposition are not the same with respect to the implicit multiplication the answer would be the same but if you would think about the problem like a computer the way to get to the answer would be different (for example the calculators I mentioned in the article would do different things internally)
Strong juxtaposition: you solve the implicit multiplication first because it has higher priority than the division. After that you do the division. Answer is 9.
Weak juxtaposition: implicit multiplication has the same priority as division. You do them left to right and actually end up with the same result even when following different conventions.
So the implicit multiplication is the reason why there are two conflicting conventions (which are necessary for the ambiguity because if there would be only one widespread convention it wouldn't be ambiguous) and the division is required to trigger the ambiguity (show where the two conventions differ).
The LTR thing is actually a very wide spread convention. I'm not familiar will all cultures on earth but my guess is of you use Arabic numerals and + and - you will work left to right for multiplication/division and addition/subtraction.
If one has a bit of math experience you can actually solve multiplication/division and subtraction/addition in any order (if you know what you are doing) like I described here: https://programming.dev/comment/5661037
I concur with everything you've written here.
I concur that a left-to-right interpretation of consecutive explicit multiplication and division is wide spread and how most calculators and computers would interpret:
a / b * c.
But the sources you quote in your blog post and the style guides I've read, state that a fraction bar or parenthesis should be used to clarify if it should be interpreted as:
(a / b) * c
or
a / (b * c)
You make the argument in your post that:
a / bc
is ambiguous (which I agree with)
but
a / b * c
is not ambiguous. Which is the part I disagree with, and I think the sources you quoted disagree with you as well. But I'm open to being wrong about that and am interested if you have sources that prove otherwise.
If I'm understanding your response correctly, you believe that
a / b * c
is unambiguous, and always treated like
(a / b) * c
because of a wide spread convention of left-to-right interpretation (a convention that we both agree exists), not because you found a source that states that.
Anyhow... I'm not out to convince you of anything and I appreciate you taking the time to explain your thinking to me.
Exactly a/b*c equals (a/b)*c but I'd instantly reconsider my position if you can show me a single calculator that would handle that diffently (credible calculator, not the once that some students program for homework assignments).
Even though one shouldn't treat calculators as some kind of authority but if all calculators handle it that way (all calculators of the five major manufacturers, Google, MathCad, Mathematics, various open source CAS) it's probably a very good indictator that it's not ambiguous.
What I also mentioned in the article is that standards and guidelines are typically stricter than most conventions in the name of clarity. So some of them even forbid things like "a / b * c" even if practically everybody agrees how this should be interpreted, just to be "extra-safe"