It’s about RTFM, not BOMDAS!

Different results can both be correct. This depends on the grammar used to parse the expression. Some handle implied multiplication with higher precedence, others don’t.

calculators

There’s this meme on the internet about two calculators (or phone calculator apps) with different results. This is a common misconception and therefore a perfect topic for my blog.

Usually it’s about the expression 6/2(2+1). Note the implied multiplication before the bracket.

This is one example:

You can trust both to give you a correct answer, because 9 and 1 are both correct. Both do exactly what is specified. So READ THE FUCKING MANUAL that you got with the calculator.

There are other articles and even videos explaining the maths behind this. As a programmer you should at least be able to find them using any web search. There you will find explanations on how implied multiplication often (but not always) has higher precedence. This is also known as abbreviated multiplication. The multiplication sign (i.e. *, ×, or ·) is omitted.

But as a programmer you must also understand that this is about parsing expressions. And even more importantly, you must understand that the correct answer is the one that is in coherence with the specifications. And for that you must talk to the clients.

But let’s have a closer look at the expression:

Our expression is this:
6/2(2+1)
That is equivalent to:
a := 2+1
6/2a
Would you really say that this is the same as:
(6/2) * a

Unless it is specified that implied multiplication is always treated the same as explicit multiplication, the juxtaposition 2a has higher precedence in the expression than the division . You can’t just replace it by 2*a. You replace it by (2*a). It does not matter if it’s a or (2+1), as we defined those to be the same.

“Six divided by twice the sum of two and one. You get one.”
is not the same as
Six divided by two, multiplied by the sum of two and one. You get nine.”

The wording is different and so are the results. But the expressions in the calculators are the same. So it’s not really about the wording but how it’s parsed.

If implied multiplication is the same as explicit multiplication, then it’s just:
6/2*(2+1) = 3*3 = 9

See the resulting syntax tree, which has the 6/2 and 2+1 subexpressions as a subtree. Therefore the two subresults (both are 3) are put in as the values for the multiplication.
The division (/) is “higher” in the tree (shown lower because the tree is upside down) than the multiplication, because the expression is parsed left to right.

If implied multiplication has higher precedence (as many would expect) it’s:
6/(2*(2+1)) = 6/6 = 1

This syntax tree has / at the “lowest” level (root of the tree) because implied multiplication (show as *) has higher precedence. The + is even higher in the tree because it’s in brackets and the value is used as the multiplicand in the expression. The brackets only influence the structure of the tree, but are not shown here.

Here’s the order of operations (precedence) as they are given in the manual for the calculator shown left in the above image:

Manual for fx-991MS – “Order of Operations” (page 34)
Source: https://support.casio.com/pdf/004/fx115MS_991MS_E.pdf

As you can see, the abbreviated multiplications (5 and 7) have higher precedence than multiplication (10). That is obviously not the case for the calculator app.

Your job as a programmer is to implement the parser so it does exactly what was specified.
As a user of a calculator you must read the manual to see how it handles implied multiplication.

It’s wrong to say that one answer is correct and the other is not, unless you know the specifications.

An calculator could just as wenn give you SYNTAX ERROR as the answer. That’s when the calculator doesn’t support implied multiplication. In that case it can’t create the syntax tree and you get that error.

Arguments for the different results:

  • 1: Many expect implied multiplication to have take higher precedence. That means expressions like 2√3/9π don’t have to be written as (2*√3)/(9*π). The juxtapositions takes higher precedence and the brackets are not necessary. Anyone not aware of this gets wrong results.
  • 9: This uses a simpler grammar and anyone who knows BOMDAS or any similar mnemonic, can just use that. All multiplication is handled the same. Not typing the multiplication sign doesn’t change how the expression is parsed. Anyone expecting higher precedence of implied multiplication gets wrong results.
  • ERROR: Same as the arguments for 9, but there is no risk of the user expecting another set of rules. This is the only behaviour that prevents false results due to ambiguity.

What people who don’t understand this, do wrong:

  • They get their calculator and type in the expression.
    This is wrong, because there are two ways and you will just get 9 or 1, but that doesn’t prove that the other result is wrong. It just shows you don’t understand the ambiguity of implied multiplication.
  • They talk about BOMDAS/PIMDAS/PEMDAS.
    That just shows they understand primary school arithmetic. But this is about something that is not handled by those mnemonics. Not one of them says anything about implied multiplication.
  • They claim that in their favourite programming language they get 9 and so it must be correct.
    But they don’t use the same expression. Instead they use explicit multiplication, which is not the same. As a programmer you must not ignore such details.
  • They claim that mathematics are unambiguous.
    That’s not true. This is about language used in mathematics. It can be ambiguous in the sense that there are different notations in use. They are all based on the works of Adam Ries, who made mathematics books to be used in schools. But there is no official rule for the precedence of implied multiplication in mathematics. I’m not aware of any standardised language that uses it. Maybe there’s something in ISO/IEC 40314:2016 or IEEE 260.3-1993, but I will not pay hundreds of dollars to read them. They probably just tell you not to use it.


Leave a Reply

Your email address will not be published. Required fields are marked *