Intuition around monoids in category theory

Question

Software developer trying to build some elementary intuition around monoids in category theory. I've read some writings on this topic, including other similar questions here on math.stackexchange, e.g.:

• Monoid as a single object category
• Category with only one object.
• Trying to understand significance of monoid as a one object category

but nobody seems to be asking or explaining it from this angle (or I'm not understanding them).

I understand the monoid concept. Take the usual example (Int, +, 0). I have a good intuition there. I know that 1 + 2 = 3, (1 + 2) + 3 = 1 + (2 + 3) and 0 + 1 = 1 = 1 + 0. I understand that + goes from one element of the Int set to another element of the Int set.

Translated to a monoid category, I now have one object A and a set of morphisms 0, 1, -1, 2, -2, ... from A to A. Identity is there, composition holds. That part is all good. Now, how do I "use" this? The above knowledge / intuition from the monoid does not seem to apply. All I have now is a bounch of arrows A -> A and whichever of these arrows I "travel" aboard, I end up at the same place, so what's the point?

What am I missing? Also, are there online resources that approach this from this angle that I can go through?

Answer 1

I have four answers, which I've given in ascending order of how satisfactory I think they are for your purposes. If you're short on time, skip to the end.

1. The most unsatisfactory answer I can give is that a category is the horizontal categorification of a monoid.

2. Another unsatisfactory answer is that there is a correspondence between one-object categories and monoids. Indeed:

   • For any small category $\mathcal{C}$ with a single object $A$, the set $\mathcal{C}(A,A)$ of morphisms $A \to A$ is a monoid, with unit element $\mathrm{id}_A$ and binary operation given by composition.
   • For any monoid $(M, \cdot, e)$, there is a one-object category $\mathcal{C}$ with a single object $A$ whose morphisms are the elements of $M$, with $\mathrm{id}_A=e$, and such that composition is given by $\cdot$.

3. A perhaps more satisfactory answer is this. Monoids can act on sets, and monoids are entirely determined by how they act on sets. Given a monoid $M$ and a set $X$, a (left) action of $M$ on $X$ is a function $M \times X \to X$, written $(m,x) \mapsto mx$, satisfying the condition that $ex=x$ and $(mn)x=m(nx)$ for all $m,n \in M$ and $x \in X$. By considering a monoid as a one-object category in the above sense, specifying a set with a monoid action is exactly the same as specifying a functor $M \to \mathbf{Set}$. Thus the one-object category corresponding with a monoid $M$ can be thought of, in some sense, as the 'generic set with $M$-action': the single object behaves as a placeholder for a set to be acted on by $M$, and the morphisms describe how $M$ acts on the set.

4. Hopefully the most satisfactory answer is this: your intuition of categories is too grounded in sets (or graphs?—see Derek Elkins's comment below). You're thinking of a morphism of a category as being a transformation from one thing to another, like a function. Whilst this intuition is helpful for concrete categories, such as the categories of sets, groups, rings, monoids, topological spaces, etc., there are many examples of categories where it is not helpful to think of the morphisms as functions (or transformations of any sort). Your question is itself an illustration of this!

Answer 2

Being a programmer myself, I understand where you're coming from. In order to "use" a monoid in programming, it has to be part of a larger category of types and functions. For that, we need a more general definition of a monoid--as an object in a monoidal category.

You probably have a pretty good intuition about a monoidal category: it's a category in which you can define a product of two objects. In programming we call it a product type, or a tuple. The tupling is associative, up to isomorphism. There is also a unit object, with the property that, when tupled with any other object, it gives you something that's isomorphic to that object. In programming that's a unit type (it corresponds to a singleton set).

I don't know what your programming language of choice is, so I'll stick to Haskell. Product of two types a and b is a pair type (a, b). The unit type is denoted by an empty tuple (). So the category of types and functions that we use in programming is monoidal (it's even more than that--it's bicartesian closed, but that's another story).

We can now define a monoid in a monoidal category. It's an object m together with two morphisms, multiplication:

mu :: (m, m) -> m

and unit:

eta :: () -> m

These two morphisms have to satisfy some laws that guarantee associativity and left and right unit laws.

The intuition is that mu assigns to every pair of elements the result of "multiplication," and eta picks the special element that's the unit with respect to that "multiplication."

This is a definition of a monoid that is much more useful in programming. You can have many different monoids sitting in the same monoidal category. You can even have multiple monoids defined on top of the same object (e.g., the integer type with multiplication or addition).

If you're curious, a general monoidal category is defined with respect to a more general tensor product that must satisfy some properties that make it associative and unital.