I read a wide range of articles and posts on a daily basis. Many of them are aimed at software developers and entrepreneurs. At least once each year or so, I run across a blog post that takes the very adamant stance that programming is not really related to math. The interesting thing is that many professional programmers in their comments strongly agree with that sentiment. And, to be honest, I saw no strong connection between programming and mathematics until I tried to get a better understanding of clinical workflow. As it turns out, programming is not simply related to mathematics, programming *is *mathematics. Having come to this conclusion, I have spent a lot of time trying to figure out how the relationship between programming and math could ever be questioned. Here is what I have observed.

**Math education is skewed to real numbers**

Every child in the US goes through a standard curriculum that begins with arithmetic in elementary school and later progresses to geometry, algebra, trigonometry, analytic geometry, and calculus. In college, majors that require math take up this sequence, which usually ends with differential equations. As a result, many college grads are well versed in math for spaces (geometry) and math for real numbers (algebra->differential equations). However, this sequence notably leaves out math that focuses on things that can be represented only with integers. That is, things that occur as discrete units. Computing is based on integers. Everyone is taught continuous mathematics (real numbers), but computing is based on discrete mathematics.

Susanna Epp, in *Discrete Mathematics with Applications, Fourth Edition*, offers this view of discrete mathematics.

Discrete mathematics describes processes that consist of a sequence of individual steps. This contrasts with calculus, which describes processes that change in a continuous fashion. Whereas the ideas of calculus are fundamental to the science of technology of the industrial revolution, the ideas of discrete mathematics underlie the science and technology of the computer age.

The formula for the area of a triangle is ** A = (b * h)/2 .** Continuous mathematics is replete with formulas, and anyone who is familiar with the rules for manipulating equations can use the formula to calculate the number or numbers sought. Obviously, life is not always about finding a specific number.

Functions are a focus of math study from algebra forward. The function ** f(x)=x^{2}**captures the relationship between a number and its square. It can be applied to any number. A function is a relationship between two sets. Anyone familiar with arithmetic and algebra can quickly calculate the square of 3.5, -17, or 100. In this example, the sets are numbers—something everyone is familiar with. However, since functions can operate on any set, not just real numbers, they can be used when the sets contain words or symbols as well (see Mathematics and Clinical Concepts, Part VI: Functions for Clinical Computing).

Consider this problem: How much is 123 x 431? Assuming you do this the old-fashioned way with pencil and paper, you know that the result is calculated by going from right to left and care must be given to align columns to retain place value. Most of us have been doing such calculations since early elementary school and have internalized the rules. The calculation has to be done in a specific manner in order to assure that the final answer is correct. That is, we follow a tried-and-true *algorithm* to determine the answer. Algorithms are math (see Algorithms in Clinical Informatics: The Path from Here to There).

Over the course of one’s math education, many formulas are learned and the algorithms used to compute their results are internalized. But what happens when a function must be computed for sets containing words and no tried-and-true formula exists? An algorithm is still required.

Consider two sets. Set ** X = {Jones, Green, Smith, …}** and represents patients at a large provider organization who must be assigned to a primary care provider. Set

**and contains the organization’s primary care providers (PCPs). A decision is made to assign each patient to a PCP. Here are the rules: 1) every patient must have a PCP, 2) no patient may have more than one PCP, 3) once a provider has reached 100 patients, no more patients can be assigned until all other PCPs have at least 100 patients.**

*Y = {Brown, Doe, Gray, …}*One way to approach this algorithm might be:

**WHILE **Unassigned Patients > 0

**BEGIN**

Select patient from Set X;

**IF **patient already has a PCP

**THEN **Select next Patient

**ELSE
**Select PCP from Set Y

**IF**PCP has >= 100 Patients

**THEN**Select New PCP

**ELSE**Assign Patient to PCP

** END …**

This algorithm computes a function between sets that do not contain numbers. This is math, and this is programming. The rules that constrain the algorithm’s operations are similar to rules such as “no division by zero” or “place the number with the fewest columns on the bottom” when multiplying two numbers.

Discrete mathematics covers many topics. Logic, functions, relations, algorithmic efficiency, graphs, sets, proofs, discrete probability, and combinatorics are taught in typical introductory courses, and usually only to math and computer science majors, which explains why most have never heard of discrete math. The algorithm above makes use of logical implication (IF, THEN), sets, and functions.

**Relations are assumed to have been a by-product of relational databases**

Functions are a type of relation. Relations are more general and have fewer rules. Relations may occur between an arbitrary number of sets. Like functions, they require algorithms to compute outcomes. The outcome of a relation is a *tuple*. For example, given the following sets: providers, patients, drugs, and dates, one could create an algorithm for a relation in which a provider selects a drug from a formulary, and assigns it to a patient on a specific date: ** (Doe, Jones, Lasix, 9/15/2014)**. The resulting tuple represents the relation “

**.” The rules are: the provider must be the patient’s PCP; the drug must be in the formulary; and the patient cannot be taking any interacting drugs. From this example, it can be seen that relations are common in health care (problem list, prescription, visit history, etc.). Relations existed prior to the invention of relational databases.**

*Current Medication List***Graphs and processes don’t use real numbers
**Graph theory began with Euler. Since then it has been applied to a number of problems. The great thing about graph theory is that it can be used to represent such complex relationships as the steps in a process, the paths through a maze, the possible paths taken using menu selections in an EHR, or simply a clinical workflow. Graphs consist of

*edges*and vertices, and edges and vertices can represent whatever is being studied at the time. On a map, the edges can be streets and vertices intersections.

If a workflow can be represented as a graph, then an algorithm can be devised that moves one through the graph. For example, if being in the waiting room is a state, and having completed registration is a state, then the algorithm that takes one from “waiting” to “registered” involves validation of demographics, insurance verification, and other related tasks. The takeaway here is that algorithms are step-by-step instructions for getting things done and they are fundamentally mathematical (all algorithms require logic).

Every software system is a collection of algorithms. Selecting a drug and assigning it to a patient is an algorithm. Selecting a product and placing it in an electronic cart is an algorithm. Both of these examples use math concepts taken from sets, logic, functions/relations, and graphs.

Knowing discrete math when writing software is like knowing pharmacology and physiology when treating a patient. The more one knows, the better understanding one has of the big picture, and very likely, the better the eventual outcome. Does one need to use a differential equation or compute an integral when creating a web application? Almost never. But try creating any application without writing an algorithm and see what happens…