# Confused by Algorithms? Introducing ‘Math Speak’: The Secret Language Nobody Told You About

## By Joseph Pacheco on May 21, 2020

*Joseph Pacheco is a software engineer who has conducted over 1,400 technical interviews for everything from back-end to mobile to low-level systems and beyond. He’s seen every quirk, hiccup, and one-of-a-kind strength you can think of and wants to share what he’s learned to help engineers grow.*

Algorithms have a steep learning curve — so the story goes. This isn’t because algorithms are inherently hard. They’re just couched in stuffy, academic language that’s akin to humans trying to make sense of assembly code. This article is about understanding the basics of that stuffy language, what I call “Math Speak,” so you can finally make progress. It’s like a secret handshake all the algorithms wiz-kids know that nobody thinks to share explicitly. Once you’ve internalized it, studying for interviews is going to feel a heck of a lot smoother.

**Here’s Why You’re Confused**

Here’s the good news: Math Speak isn’t actually that hard to understand. And if the math and CS worlds were better at teaching, this article wouldn’t be necessary. But don’t take my word for it. Dr. Leslie Lamport (the 2013 Turing Award winner) explains:

Why is 'two plus two equals four' considered simple but a logical operation like 'an element of' is hard to understand for most people? ...Why should 'element of' seem frightening when 'plus' seems so easy? It's just a matter of not being familiar with it, and this is not all your own fault—mathematicians are terrible at teaching it.

To walk you through a full example of this language at work in algorithms, let’s take a look at the *Algorithm Design Manual* by Steven S. Skiena, one of my favorite resources. Consider the following excerpt on graphs:

Graphs are one of the unifying themes of computer science — an abstract representation that describes the organization of transportation systems, human interactions, and telecommunication networks. That so many different structures can be modeled using a single formalism is a source of great power to the educated programmer.

Based on this, you might be wondering what they even mean by “graph.” This doesn’t sound like any graph most of us have ever seen, namely one with an x-axis, a y-axis, and a plot of values. Turns out, it’s related (but only distantly). It’s best to think of this as a whole other perspective on the term “graph” that has little to do with the definition we’re all familiar with. Skiena continues:

More precisely, a graph G = (V, E) consists of a set of vertices V together with a set E of vertex pairs or edges. Graphs are important because they can be used to represent essentially any relationship. For example, graphs can model a network of roads, with cities as vertices and roads between cities as edges... Electronic circuits can also be modeled as graphs, with junctions as vertices and components as edges.

Now while that may make graphs seem like impressive things, there’s only one sentence in this entire introduction that defines a graph itself:

...a graph G = (V, E) consists of a set of vertices V together with a set E of vertex pairs or edges.

If you’re struggling to make sense of that, you’re not alone. In order to get anything from this book, you need to already have an understanding of the language that mathematicians and computer scientists use to discuss these kinds of formal concepts. And though courses like Discrete Math exist in CS degree programs, I've seen first-hand how even those supposed entry level curricula can gloss over the entire idea of explaining Math Speak ... and get right into using it to confuse you. We don’t expect high school freshmen to read the *Odyssey* in Greek without learning the language, but we expect CS students and self-taught coders who want to pick up algorithms to read things like the above without teaching them the basics of Math Speak.

**Here’s How Math Speak Works**

Math Speak is just a way to describe concepts purely in terms of other mathematical (or CS) concepts. To understand something like a graph in CS, you just need to understand the other ideas being referenced. Skiena’s definition is given in terms of mathematical sets. A set is just a collection of distinct items, and, according to this definition, a graph is just a thing that consists of two such sets: one of “vertices” and one of “edges”. This math-style definition can be represented visually like so:

A vertex (singular of vertices and also known as a “node”) is just a fancy way of referring to a thing in a graph, and an edge is just a relationship between two of these things. These things can be pretty much whatever data point you want: numbers, people, words, locations on a map, ideas, etc. Likewise, the “relationships” between them can be whatever is meaningful for what we want to represent with the graph. For example, we could have a graph where the vertices/nodes are cities and the edges/relationships are the distances between those cities. Let’s update our visual to represent this example:

If you think about it, this makes a lot of sense. When we want to see how a bunch of things relate to one another, we use a graph. The graph consists of the things themselves along with the ways they do in fact relate to one another. It’s really that simple. It just sounds weird upon first glance because of the math-style way we talk about it. This style is really just closer to how we might represent a graph in code (e.g. an array of things and an array of relationships). But it does feel a bit robotic to think of something so simple in terms of distinct sets, which is why we usually represent graphs visually as follows:

This gets right to the point by focusing on the things and their relationships in a much more intuitive way. But it is nonetheless the exact same thing: a set of vertices in blue and a set of relationships in red. And there you have it, something that at first seemed esoteric, but which is in fact nothing more than common sense.

**Here’s How Math Speak Is Written**

Now, there is an additional layer that trips people up: how this is all *written*. You may also have noticed what appear to be functions and variables thrown into the graph definition. Math Speak has this habit of adding labels to each of the things it’s talking about. The labels tend to be single letters (but not always), and introduced immediately after the thing being discussed is introduced. For example, after “a set of vertices” is mentioned, the label “V” is immediately inserted as a shorthand for that set of vertices. This peppering of additional detail can make it hard to parse sentences in math speak, but one does eventually get used to it. If your brain shuts down on contact (like mine used to), try to read the sentence first without the labels so its more like natural English.

Sometimes, the labels can be a bit more complex. For example, after “a graph” is introduced, it is followed by “G = (V, E)”. This is just a mathematical way of labeling the graph and then giving more detail about what it is. “G” is the single-letter label for some graph we have in mind, while “(V, E)” is what the graph consists of. The fact that “V” and “E” are in parentheses together simply means the thing represented by “V” and the thing represented by “E” are part of the same overall thing (in this case, the graph). Again, it's a whole lot of complexity that means something very simple. The labels are just there to create a shorthand for referencing each thing later.

**Key Insight: Comment Algorithms Like Code**

Math Speak is great for encapsulating a ton of information in really concise, ultra-precise language, but which is anything but intuitive at first. *When you encounter it, you have to translate and expand it into more natural, readable terms*. Think of this like writing good comments for your code. Every line of code does something, but describing it in paragraph form is often critical for making sense of what it actually does. Do this for every algorithmic topic you encounter, and even the most high-minded books and advanced topics will start to seem a lot less scary — because you’ll finally be able to see them for what they actually are.

The bottom line: Do not be intimidated by stuffy, academic, math-style language when studying algorithms. It sounds like it was written by robots for robots, but once you understand the basic rules (and build some habits with them), everything will start to make a lot more sense. It’s well within your reach to understand.

## Discussion