APL began life as a mathematical notation, created by the Canadian computer scientist Kenneth E. Iverson. Over the years it evolved into the APL programming language. There are several versions of APL but they all follow the same order of operations.
When I started learning APL, one of the trickiest things was reprogramming my brain! This was because APL does not follow a traditional mathematical order of execution. The special symbols do take some getting used to but trying to change the way you think is much trickier.
BODMAS/BIDMAS vs APL
In traditional mathematics, the correct order of execution is BODMAS. This is also sometimes referred to as BIDMAS, where the only difference is I, which stands for indices. BODMAS stands for: brackets, orders, division, multiplication, addition and subtraction. When evaluating mathematical expressions, you would work from left to right using BODMAS. First resolving brackets, then orders, and so on.
In contrast to BODMAS, APL evaluates mathematical expressions from right to left unless the order of execution is modified by parentheses. Next, I will show the differences.
To demonstrate, we will look at the following expression: 10 × 5 + 5
As you can see, we have both multiplication and addition. So, given the order of BODMAS, we know the multiplication will be resolved first, then the addition. Meaning 10 × 5 will be resolved first, then will be added to 5, giving us 55.
However, in APL, the above expression would perform differently. It would be executed as follows: 5 + 5 would be resolved first, then multiplied by 10, giving us 100.
Another example of this would be the expression (10 × 20 - 5) ÷ 15.
In traditional mathematics, the brackets would be resolved first also using BODMAS. This means we would perform 10 × 20 giving us 200, then subtract 5 leaving us with 195. We then resolve 195 ÷ 15, giving us 13.
In APL, we would still resolve the brackets first, but this will result in a different answer. 20 - 5 gives us 15, then multiplying that by ten gives us 150. Finally, then we resolve 150 ÷ 15, giving us 10.
The above examples aren't very complex, unlike some real-world application of mathematics.
For example, we build and maintain a system containing pension calculations. So, when we receive specifications for calculations, we must be aware of the order of execution. This, of course, has an impact on how much time some projects may take us. When we are working with actuaries to refine calculations this can prove difficult.
This is because actuaries define the calculations using a traditional mathematical approach. The same issue occurs internally when our QA is trying to test our calculations. Thankfully, our QA is much more forgiving.
Sam is an APL Developer at Optima Systems. He started at Optima in 2012 as an apprentice straight after finishing College. Sam decided to take Computing whilst studying at college, yet, he never intended to but, he thought it sounded interesting at the time. Sam’s original career plans involved studying Meteorology at university, to become a Meteorologist. His plans changed when he realised how much he enjoyed code. More about Sam.