### Fun with Math …

You’ve probably seen memes like the one shown here while surfing Facebook or Twitter. It’s basically an exercise in the Order of Operations, the order in which math operations are solved in a formula. In this case, according to PEMDAS, the answer is 1 because the division operation is taken care of first and then the rest from left to right.

It’s okay as an example of why basic math skills are important but someone might ask “Well, I know how to program in (insert programming language here) and I can just enter that as a formula and let the computer take care of it.”

Can you?

Let’s look at another example I saw yesterday:

a = (100 + 1.0/3) - 100 b = 1.0 / 3 True or False: a == b

So the question is whether *a* is equal to *b* since formula *a* simply adds and then subtracts 100 to the same operation shown in formula *b*. Both formulas *should* work out to the same thing – 0.3333…. The original question that I saw online assumed that the answer should be the same in “virtually all programming languages”.

Let’s try it in SQL Server first. The SQL code below evaluates both formulas, stores the results in variables and then compares those variables to decide what to display. The results then show the two formulas are equal.

That’s mostly as expected. I used a SQL Decimal data type and allowed for 10 digits after the decimal point but SQL didn’t use all of them – it rounded off the last few even though it could have continued with a repeating decimal.

Now, let’s look at Microsoft C#.

This code uses the Decimal type in C# to solve the same formulas and then displays the results to the Windows command line as shown on the right side of the screenshot above.

The results are the same but they’re *not*. The second formula returns *two more decimal places* and the literal comparison made by the program says they are not equal, even though for most purposes they are.

The difference gets a little more obvious if we make a small change to how the program stores the results of the formulas and change the data type to a Double:

C# processes Doubles a bit differently than Decimals so now the values actually do come out differently *even though we’re working with the same numbers*.

### Why is this important?

In programming, you give the computer a lot of instructions for making decisions because it can’t make any on its own. Computers are actually quite stupid; they know how to juggle 1s and 0s in exactly the way they’re told.

Just like many *people*, they also have a number of bosses. Different processors will have different methods for handling certain operations. Then there’s the translation of programming languages like C# or SQL to the ones and zeroes of machine language. Those languages are *abstractions* for the sake of the human trying to communicate with the machine but, if you’ve ever tried to translate one language to another or even looked at a Picasso painting, you know that detail can get lost in abstraction. The last example above shows a result that is *wrong*; formula *a* should be an endless repeating decimal but, because of the way C# handles that data type and the specific language of the formula, it’s not.

None of this even takes into account the actual skill of the programmer or the people gathering requirements for the program. The simple choice to round off a number to the required precision could make all the difference.

What if it’s a program that’s returning a success or failure based on such a comparison? It could be the programming that analyzes your credit card swipe at the gas station or something as serious as medical testing software or a manufacturing program that’s working with machined parts or electronics. The wrong decisions made by the program might be hidden a few calculation levels behind a final figure on a report or might lead to false results that determine if your card is accepted, the right diagnosis is made or whether the parts are shipped and included in a critical assembly. Even short of those possibilities, it might just mean a lot of man-hours spent trying to track down why the software is not working the way it should.

The first answer is, of course, testing, more testing and more testing after that. Good programmers throw a lot of sample data and test cases at a program to try to eliminate possible errors like these and even then, something might turn up later. Even with testing, however, programmers need to be comfortable with numbers and to have some decent math skills so they can anticipate and understand the situations like the one shown here and never, *ever, *put too much trust in a machine that only knows how to play with ones and zeroes.

Math isn’t just for programmers, either. Computers make wonderful tools but they make terrible bosses. Numbers affect every part of the modern life and the ability to communicate how those numbers relate through mathematical notation is an incredible human accomplishment. It’s not always easy but it’s possible and the more you learn to appreciate and work with numbers, the more capable you are.

For a look at some math concepts made easy and fun, check out MathsIsFun.com.