Your Notation for Your Thoughts

In his 1980 paper Notation as a Tool of Thought, Iverson describes the "serious deficiencies" of mathematical notation, mainly how it is context-dependent. While this paper is much revered in the APL community, it is important to realize that working in absolutes like this can often be counterproductive. This post is intended as a jumping-off point for creating your personal notation, though at the end is a section about mine.

Types of notes

Doing any sort of (somewhat advanced) mathematical work, it is immediately clear that there's two very distinct types of annotation. If you're trying to prove a certain statement, you'll produce a lot of bits of notes during exploration that might or might not turn out to be useful in the final proof; after you've collected enough bits you realize how you should connect them and complete the proof. You then neatly write the finished proof in your notebook, copying over the relevant notes while cleaning them up. The finished proof and the notes that led to it are very different pieces of text. While you might want to read the former months later, perhaps studying for an exam or trying to see if it can generalize further to new needs, the latter will hardly be useful to you after the proof is complete and they are realistically going to be thrown out, whether that's immediately or when cleaning up your desk months later.

I've been in a math olympiad team for about four years⁽¹⁾, which has led me to develop a third type of note. Managing time is really important during a competition, which means you'll need to work really quickly. Not every thought can be carried out in your head, so notes are still helpful, but often you might omit big steps you did without the piece of paper. More importantly, assuming your solution ends up being correct, you won't really need to look at the notes again even while working on the problem, since the time span is often short enough you'll remember your working.

Throughout the post, I will distinguish these three types of notes. Proof-like notes are long-term notes, working out notes are short-term notes, competition notes are instant notes.

Your brain is not a computer

Iverson remarks that

Not only are [programming languages] universal (general-purpose), but they are also executable and unambiguous. Executability makes it possible to use computers to perform extensive experiments on ideas expressed in a programming language, and the lack of ambiguity makes possible precise thought experiments.

While this is definitely true, it's also important to realize that executability isn't always something that is relevant. If you're in a competition, you obviously aren't allowed computers. If you're doing proofwork, you might want to not use a computer for whatever reason. You could also just be working in a field where it's really hard to simulate something, but comparatively easier to just do the working out yourself. If you don't think you will need to ever execute your notes, there is no reason to take them in a manner that is executable.

Similarly, Iverson cites the universality of programming languages as a strong benefit for a notation for thoughts. Universality here means that the same language can be applied to a variety of fields and context; which is the opposite of mathematical notation, which is described to most of the time be context-dependent. While this seems like a reasonable want, it starts to break down if you think about it more. If you want the notation to cover a large surface, and yet still be expressive, it will need many primitives. If you're using some notation to do group theory, you'll want to have a way to express a group element acting on an object; if you intend to use the same notation to do elementary geometry, it's unlikely you'll ever want this feature. Of course, you can just ignore its existance if you don't need it. However, notation evolves (this will be expanded upon later), and if you feel the need to introduce a new symbol for a common elementary geometry operation, you will have to remember all the notation used in all the other fields you work in, lest you lose the universality. Perhaps it's then better to just give up on the universality premise from the beginning, and recognize that different areas of work will use clashing notation.

You know what you mean

Writing short-term notes and especially instant notes, you can keep most of the context of what you're doing in your head. If you need a shorthand for something that's specific to the problem at hand, you might not even need to write down its definition; you'll probably know what you mean. Similarly, you might want to tweak the definition of a symbol to be more useful in the current context, or you might want to temporarily introduce notation from a different field since you're solving a problem in a non-standard way⁽²⁾.

...but you won't know what you meant

This definitely does not apply to long-term notes. I can guarantee you that when you're looking at your proof eight months after you wrote it, you are not going to remember what that weird squiggle meant. Write everything that's relevant down.

Precedence is fine

Iverson really disliked operator precedence, and designed APL's simple system of long right scope instead. That's great for a computer, but you'll know what you wanted to mean if you use a little bit of precedence. For example, it's really nice to have $=$ have a very low precedence. Don't go crazy of course, and use parentheses where they would be clearer.

The page has two dimensions

Mathematical notation is well-known for being 2D, which is mostly what makes good layouting programs hard. This is how you'd universally write "the sum, for each number between 1 and 10, of the number times its successor":

In case you need a refresher, $\sum$ indicates a summation, with the thing written below it indicating the starting number ($1$), as well as giving a name to the number that's being changed ($n =$), the thing written above it indicating the ending number ($10$), and everything after it indicating the expression that will be summed, with $n$ being replaced each time by the current value of the summation.

APL, the notation that Iverson proposes as a replacement for traditional mathematics, is a programming language, and a very old one at that; mathematical notation had a gradual process of linearization that made it typeable on a mainframe terminal. Linearization means that the two dimensions became one. For example, a simple way to linearize the above example could be something like

where $\sum$ becomes a normal* function, with the asterisk indicating that its input types are a bit weird; in any case it became 1D and can now be typed on your keyboard very easily without needing a layout engine, at least assuming you have a $\sum$ key, but that was the assumption with typing APL in the day as well.

Again, you're not writing for a computer. Your pen or pencil or whatever can move across the page as you wish, writing symbols big and small. Traditional $\sum$ notation is really useful and easy to read and write, there's little point in linearizing it.

You can invent whatever you need

In his famous Epigrams on Programming, Alan Perlis says

It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.

This sentece is often quoted by APL evangelists to mean that APL, which only has the multidimensional array as a data structure, is better than traditional languages, which have many collections, since every function works with the same thing. The quote, as far as I can tell, has in general always been understood to be about economy. Program size is (and especially used to be) finite, so if you have a limited amount of functions you can fit, you'd want them all on the same structure. Taking notes, this definitely does not apply. Your brain is fantastic at knowing when something is useful. Have a set structure with set operations, and use it when doing set theory. Have a multiset structure with multiset operations, and use it when you're working with roots. Have an associative structure, which is useful all the time. And again, if you know you definitely won't need something in a context, you're free to reuse its syntax and primitives for other things. If you need a weird data structure, don't think about how you are gonna express it in terms of the ones you already have; just manifest it alongside all the operations you want and it's magically there. Not needing executability is awesome.

Notation evolves faster than languages

Of course, programming languages evolve all the time, some slower, some faster. But your notation has no reason to care about being fixed in time. If you find that a certain construct is useful all the time, commit it to your memory and start using it everywhere. If you think something is useless, consider removing it. Of course, be careful when you remove something; old long-term notes might still be using it. Looking through them, if you find it used a bunch, perhaps it was useful after all, and you just are now doing something different enough it doesn't matter. Then you can put it in the back of the memory, just making sure it's not completely forgotten, or you'll be very confused later, especially if you accidentally reintroduce the same syntax for something else. If you find it once or twice only, add some marginalia to the long-term note explaining the syntax and then feel free to drop it from your mind. Good notation evolves alongside you.

It might be good to keep a few pages of your long-term notes dedicated to annotating what the more uncommon notation means. I'm really bad at this, but luckily I can usually remember after looking at old notes for a bit; if you feel you won't be great at that, do write things down.

My notes

For this final section it might be interesting to look at one of my own notes. Sorry for the terrible picture quality.

This is a proof; the statement in traditional math notation would be

For every positive integer $n$, the set $\left\{\operatorname{ord}_n\!\left(x\right) \mathrel{}\middle|\mathrel{} x \in \left(\mathbb{Z}/n\mathbb{Z}\right)^\times\right\}$ and the set $\left\{d \mathrel{}\middle|\mathrel{} d \mid \lambda\!\left(n\right)\right\}$ are equal.

where $\lambda$ is the Carmichael function. Here's my best attempt at the same proof in mathematical notation.

Take $n = \prod p_j^{e_j}$ and consider a divisor $d \mid \lambda\!\left(n\right)$, and call it $\prod p_j^{a_j}$. Notice that $\exp\!\left(\left(\mathbb{Z}/n\mathbb{Z}\right)^\times\right) = \lambda(n)$. Sylow decompose $\left(\mathbb{Z}/n\mathbb{Z}\right)^\times$ into $G_j$ such that $\exp\!\left(G_j\right) = p_j^{e_j}$. Now, by definition there exists $g_j \in G_j$ such that $\operatorname{ord}(g_j) = p_j^{e_j}$; consider $g_j^{p_j^{e_j - a_j}}$, which clearly has order $p_j^{a_j}$. Therefore $\operatorname{ord}_n\!\left(\prod g_j^{p_j^{e_j - a_j}}\right) = \prod p_j^{a_j} = d$, so we found an element of $\left(\mathbb{Z}/n\mathbb{Z}\right)^\times$ with order $d$, hence the thesis.

Some interesting bits might be $\rlap{\(\!\sim\)}{\|}$ for the set of divisors, $\exists$ giving back one such value and $\exists?$ being a predicate and $\;\exists$ giving back all such values, $\overset{.}{\mid}$ for the order of something (dyadically $\operatorname{ord}_\alpha\!\left(\omega\right)$, monadically inferring $\alpha$ from context), mixing $\star$ and superscripts both for indicating exponentiation, using $\times\!/$ for indicating the product instead of $\prod$, $\exp$ for the group exponent not having a symbol at all. None of these are standard, but I know what they mean, and so I can comfortably read back this proof.

Footnotes

1. With mixed results.

2. We all love complex bash, right?.