Confused about why all morphisms for a monoid are not the same as the identity morphism

Question

I am busy reading Bartosz Milewski's Category Theory book for programmers and I'm struggling with the depiction of non-identity morphisms when moving between describing a monoid as a set and a monoid as a category.

I understand that when viewing a monoid (eg. a string) in the context of as a set, we are interested in describing various functions that make use of the 'append' characteristic, for example a function that appends "dog" or a function that appends "mmm" to whatever input it receives. These functions will, respectively, map their input to another element within the set of strings. This obviously includes the possibility of appending nothing.

When we view this monoid in the context of as a category, as far as I understand, we are zooming out to a level of abstraction where this monoid object represents the entire 'string' type and we are no longer interested in how elements are mapped to each other within this type, as we have represented this entire type as a singular dot/object.

Following from this, I would assume that at this level of abstraction, all functions that were described in the 'Set' context would look identical, as they all map string -> string. In my mind, this means that in the context of a category, the identity function (appending nothing) would look identical to the AppendDog or AppendMmm functions mentioned earlier, or any other function for that matter.

My reasoning is obviously incorrect though, as looking at this diagram in the book, morphisms that go from the monoid object to itself, are shown as unique entities:

As a closing statement/summary: I do not understand why we are still interested in depicting functions within a monoid set once we have abstracted it to a category. Once the set becomes an object in a category, where that object represents the entire type, would all functions within that set not all look like identity functions, as from our new vantage point, they all seem to start from that type and return to that type.

I hope I've made my confusion clear. Thanks in advance for any help!

Rasp

Please avoid saying “in the context of a set” / “in the context of a category”, be specific what you mean. There's at least two distinct notions that could be relevant here: 1. the category which has all monoids as its objects and monoid homomorphisms as arrows (aka the category of monoids) 2. the view of a given monoid as a category with only a single object (the monoid) and its members as the morphisms. – Decathlon

Apologies for the ambiguity. I had originally written it as "a monoid as a category" (2). I will edit and make a note of this – Rasp

"When we view this monoid as a category, we are no longer interested in how elements are mapped to each other within this type, as we have represented this entire type as a singular dot" -- No! We have represented the monoid as a dot, plus all its morphisms, plus the operation that combines two morphisms into one. "all functions that were described in the 'Set' context would look identical, as they all map string -> string" -- No! There are in general no functions in the homset of the category associated with a monoid. – Pepi

A morphism is essentially a "labelled" ordered pair. The source and target are not sufficient to define a morphism. Once you have your set of morphisms, the composition operator defines which compositions are "equal". If f, g : A -> A, it's the composition operator that says whether f . g and/or g . f "equal" the identity morphism, not anything else inherent in f or g. – Veron

Answer 1

What I believe you are observing is the fact that every monoid is homomorphic to the trivial monoid. If you just look at the dot-and-arrow diagram of any monoid, it is also a valid diagram of the trivial monoid, but this diagram is not the whole picture.

When you are "abstracting" you are essentially throwing away the equivalence relation on the monoid and supplementing the weakest one possible. Append "mm" and Append "" are different, but the diagram doesn't illustrate that. It's possible to imagine that they are equal and you will get a valid monoid, but that changes the equivalence relation.

Even if we discard some of the specifics, the fact that they are unequal (or at least might be unequal) should not be discarded. It's important to the structure.

Ejaculation

Thank you for this, I was discarding too many details when abstracting. You mentioning that morphisms being unequal despite obviously starting and ending at the same object is a detail that I need to accept. – Rasp

@Rasp That was a confusion I had for a long while too. It's easy to accidentally get the idea that since a morphism is drawn as an arrow between two objects that all that defines a morphism are its source and destination objects, but that's not true! "Morphism from A to B" is sort of a "type" of morphisms, but distinct morphisms can exist that have this type (they go from A to B). The category laws tell you some morphisms must be equivalent (such as (f · g) · h and f · (g · h)), but you can't tell that just from the "type". – Addition

And identity morphisms aren't just any morphism that happens to start and end at the same object, they are special ones that have the particular property that f · idA = idB · f = f. In the monoid category where morphisms are appending strings, append "dog" and append "mmm" do not have this property, so they can't be identity morphisms. – Addition

This answer seems dangerously wrong to me. The dot-and-arrow diagram of most monoids are not valid diagrams of the trivial monoid, because there's too many arrows. The claim that "mm" and "" aren't illustrated to be different by the diagram is sort of technically correct, but if you take the whole definition of the category, they are clearly different because the composition does different things with them. Composition generally isn't drawn in dot-and-arrow diagrams, but that's a limitation of the representation, not a limitation of the abstraction. – Pepi

@DanielWagner I put "abstraction" in quotation marks for precisely this reason, it's not actually an abstraction even though the OP calls it such. I'm not sure what your point is about the dot-and-arrow diagrams. If you have an example diagram of a monoid that can't represent the trivial monoid then that might help? Butit would have to be that unless the diagram conveys two morphisms are unequal (and I don't see how it can), that could potentially be the trivial monoid, by the fact that the trivial monoid is initial. – Ejaculation

@WheatWizard I think I put too much emphasis on 'abstracting' as opposed to simply representing the monoid in a different way (as a category - where all morphisms are still important). – Rasp

Answer 2

Perhaps a concrete example would make this easier to discuss. So here's my concrete example:

   t
┌────┐
│    ▼
└─── • ◀──┐
     │    │
     └────┘
       f

This is a category with one object (•) and two morphisms (t and f). Is this a complete category definition? No, we need another thing, namely the definition of composition. I'll give it as a lookup table.

f ∘ f = f
f ∘ t = t
t ∘ f = t
t ∘ t = f

Is this a complete category definition? No, we need one more thing, which is we need to identify one morphism per object that serves as an identity. For this category, there is just one object, and f has the right behavior for that object.

Is this a complete category definition? Yes! You might want to verify the category laws -- that f ∘ x = x ∘ f = x, and that (x ∘ y) ∘ z = x ∘ (y ∘ z) -- but you're also welcome to take my word for it. (If it helps your intuition for those proofs, you might want to read f as "false", t as "true", and ∘ as XOR.)

Okay, so that's a one object category. Hopefully it's clear that not all the morphisms are the same. Surely true and false seem like distinct concepts!

Now compare the above definition of a category to the following definition of a monoid. To define a monoid, we have to give a triple (M, +, 0) of a set, a binary operation, and an identity. Define:

M = {f, t}
f + f = f
f + t = t
t + f = t
t + t = f
0 = f

This specifies the monoid of booleans under xor. Note how similar our two developments were. For the category, we gave a dots-and-arrows diagram that identified two arrows, f and t, while for the monoid definition, we gave a set containing two elements, f and t. For the category, we gave a composition operator that combined two morphisms into one, while for the monoid, we gave an operator that took two elements of the set and returned an element. For the category, we identified f as the identity morphism, while for the monoid, we identified f as the identity element. For the category, we proved that ∘ was associative, while for the monoid, we proved that + was associative. For the category, we proved that composition with f does nothing, while for the monoid, we proved that adding to f does nothing.

The data we need to provide to define a monoid and the data we need to provide to define a one-object category are identical!

Pepi