Category Theory
Zulip Server
Archive

You're reading the public-facing archive of the Category Theory Zulip server.
To join the server you need an invite. Anybody can get an invite by contacting Matteo Capucci at name dot surname at gmail dot com.
For all things related to this archive refer to the same person.


Stream: practice: software

Topic: Monoidal Categories in Catlab


view this post on Zulip Paul Lang (Feb 14 2025 at 21:40):

Hi all, I'm a systems biologists with some difficulties to understand monoidal categories. In Seven Sketches and elsewhere, these are visualized as wiring diagrams, but to me it occurs that they could also be visualized as shown in the example below on the right, where colors indicate one of many possibilities for the functor :C×CC\bigotimes: \mathcal{C} \times \mathcal{C} \rightarrow \mathcal{C}
image.png

If that's correct, I'm wondering what it means for this example from the Catlab docs:

@present Cooking(FreeSymmetricMonoidalCategory) begin
  (WholeEgg, RawEgg, Shell, Egg, Pan, Cheese, Scramble)::Ob
  crack::Hom(WholeEgg, RawEgg⊗Shell)
  # fry::Hom(RawEgg⊗Pan, Egg⊗Pan)  # Let's ignore for now
  # scramble::Hom(RawEgg⊗Cheese⊗Pan, Scramble⊗Pan)  # Let's ignore for now
end

Since \bigotimes is used in the Homs, it seems to me that I am working with the product category Cooking×Cooking\mathcal{Cooking} \times \mathcal{Cooking} here, not with Cooking\mathcal{Cooking} directly. Is that correct?

If so, what does Cooking\mathcal{Cooking} look like then? Certainly it must contain WholeEgg, RawEgg, Shell, Egg, Pan, Cheese, Scramble (and munit()) as objects; and due to crack::Hom(WholeEgg, RawEgg⊗Shell) (i.e. crack::Hom(munit()⊗WholeEgg, RawEgg⊗Shell)) it must also contain c1::Hom(munit(), RawEgg) and c2::Hom(WholeEgg, Shell). Due to symmetry I would also assume that c3::Hom() and c4::Hom() are part of Cooking\mathcal{Cooking}. Does that seem right?

If so, I still don't know how exactly the ⊗ functor looks like. I see multiple possibilities (trivially it could even send all objects to munit() and all morphisms to id(munit())), but it does not seem necessary to pin it down to one of the possibilities.

Thanks in advance for your help!

view this post on Zulip Kevin Carlson (Feb 14 2025 at 22:00):

Hi Paul! I'm not sure how to read your visualization. Are you defining a monoidal product on the category 1BC1\to B\to C? If so, it looks as if you're trying to define 1B=1C=1.1\otimes B=1\otimes C=1. But that's not allowed: 11 has to be a unit, so 1B1\otimes B has to be B.B.

view this post on Zulip Kevin Carlson (Feb 14 2025 at 22:01):

I similarly can't parse the coloring of the arrows on the left in any consistent way.

view this post on Zulip Kevin Carlson (Feb 14 2025 at 22:02):

Regarding your question, no, RawEggPan\mathrm{RawEgg}\otimes \mathrm{Pan} is an object in Cooking\mathsf{Cooking} itself, namely, the tensor product of the two objects RawEgg\mathrm{RawEgg} and Pan\mathrm{Pan}. In the same way, if I consider the monoidal structure on the category of sets given by the cartesian product and I mention S×T,S\times T, I'm talking about the set S×T,S\times T, not the object (S,T)(S,T) of Set×Set.\mathsf{Set}\times\mathsf{Set}.

view this post on Zulip Kevin Carlson (Feb 14 2025 at 22:04):

How it works is that Cooking\mathsf{Cooking} is the symmetric monoidal category freely generated by the provided data. Every pair of objects in a symmetric monoidal category must have a tensor product, which is how you produce that RawEggPan\mathrm{RawEgg}\otimes \mathrm{Pan} object: you wouldn't be finished freely generated an smc if it weren't there yet!

view this post on Zulip Kevin Carlson (Feb 14 2025 at 22:05):

You do not need to see crack\mathrm{crack} as having domain munit()WholeEgg\mathrm{munit}() \otimes \mathrm{WholeEgg}, any more than you need to see a function AB×CA\to B\times C as "really" having domain 1×A.1\times A.

view this post on Zulip Kevin Carlson (Feb 14 2025 at 22:05):

This should clarify why c1,c2c_1,c_2 need not exist. You can have homs between tensor products of objects that are not, themselves, tensor products of homs.

view this post on Zulip Kevin Carlson (Feb 14 2025 at 22:06):

I have no idea what c3::Hom()c_3::\mathrm{Hom}() would even mean: homs have to have a domain and a codomain.

view this post on Zulip Kevin Carlson (Feb 14 2025 at 22:08):

How the \otimes functor works, overall, is that Cooking\mathsf{Cooking} has as objects all formal tensor products of strings of generating objects, such as WholeEggRawEggShellWholeEgg.\mathrm{WholeEgg}\otimes \mathrm{RawEgg}\otimes \mathrm{Shell}\otimes \mathrm{WholeEgg}. Then the tensor product just takes two of these strings and concatenates them! Similarly, morphisms are built by tensor and composition out of generating morphisms, which in this case are just identities, crack,\mathrm{crack}, and the transposition symmetries such as τ:WholeEggRawEggRawEggWholeEgg.\tau: \mathrm{WholeEgg}\otimes \mathrm{RawEgg} \cong \mathrm{RawEgg}\otimes \mathrm{WholeEgg}.

view this post on Zulip Kevin Carlson (Feb 14 2025 at 22:08):

There's a lot going on here, but I hope that helps!

view this post on Zulip Paul Lang (Feb 14 2025 at 22:43):

Hi Kevin, thank you for your quick and detailed response. Yes, I was trying to define a product on 1BC1 \rightarrow B \rightarrow C; would this coloring make sense (red maps to f, green maps to g, black maps to the respective identity morphisms; 1⊗1 is sent to 1, 1⊗B, B⊗B and B⊗1 are sent to B, the rest is sent to C)?
image.png

Anyway, as your response suggests, the picture above is not a good MWE for the Cooking category, as I would also have to include 1×B,B×C,B×...×C1 \times B, B \times C, B \times ... \times C etc on the right side, so I would never be done drawing. Is the illustration below a better way to think about monoidal categories and the functor :C×CC\bigotimes: \mathcal{C} \times \mathcal{C} \rightarrow \mathcal{C}?
image.png

view this post on Zulip Kevin Carlson (Feb 14 2025 at 23:42):

That picture is now a complete description of a monoidal structure on 1BC1\to B\to C, as it looks like you’ve realized: we could define it concisely as the monoidal structure given by coproduct, or in order theoretic terms, by join.

view this post on Zulip Kevin Carlson (Feb 14 2025 at 23:42):

It’s true that monoidal categories are usually infinite for reasons you were starting to think about in the crossed-out section.

view this post on Zulip Paul Lang (Feb 16 2025 at 19:16):

Thanks Kevin, I was thinking about your responses a bit and I assume freely generated means that you use the tensor product to generate an infinite set of objects from a finete set of objects.

This would then mean that

@present C1(FreeCategory) begin
  (A, B, C)::Ob
  f::Hom(A, B)
  g::Hom(A, C)
end

contains three objects, A, B and C, and two non-identity morphisms, f and g; and while the ThCategory would allow for a morphism h::Hom(B, C), to exist C1 does not contain it. C1 is a category with a finite number of objects and morphisms and can be presented as a graph via to_graphviz(C1).

But what about a monoidal category:

@present C2(FreeSymmetricMonoidalCategory) begin
  (A, B, C)::Ob
  f::Hom(A, B)
  g::Hom(A, C)
  h::Hom(A⊗B, C)
end

As before, this category contains the objects, A, B and C and two morphisms, f and g. Additionally, it contains munit() and the morphism h. As before, while the ThSymmetricMonoidalCategory would allow for a morphism Hom(B, C) to exist, C1 does not contain it. In contrast to before, however, C2 has infinitely many objects and morphisms. Although not explicitly specified above, C2 contains objects like A⊗B, A⊗C, A⊗...⊗A, and morphisms like f⊗g::Hom(A⊗A,B⊗C), f⊗h::Hom(A⊗(A⊗B), B⊗C), g⊗...⊗g::Hom(A⊗...⊗A, C⊗...⊗C), etc. Since C2 is a category with an infinite number of objects and morphisms it cannot be presented as a graph (consistent with to_graphviz(C2) erroring out). So the picture on the right below is not a complete picture of C2 (though I hope the color coding is consistent with the functorial property of ⊗ this time - dotted morphisms map to identities).
image.png

Also, a wiring diagram is never a complete representation of a monoidal category. It does a completely different thing: it is just one of many "programs" that can be written in the language of a certain monoidal category. Is this correct? I think some of my confusion came from asking myself how graph presentations of a category and wiring diagrams can be interconverted . But it seems that was a wrong question - they can't.

One thing that still puzzles me is whether the monoid presented below is also a monoidal category. Cause that would contradict my conclusion from above that "a category with an infinite number of objects (i.e. here M×...×MM \times ... \times M) and morphisms it cannot be presented as a graph"
image.png

view this post on Zulip Kevin Carlson (Feb 17 2025 at 00:20):

Yes, everything up to your last question sounds right. A string diagram in a (symmetric) monoidal category represents a single morphism, not the whole category, and in the great majority of cases a symmetric monoidal category is infinite.

view this post on Zulip Kevin Carlson (Feb 17 2025 at 00:22):

However, such an object can still be presented by a finite graph, which is exactly what the “@present” macro does! It’s specified as “the free symmetric monoidal category generated by the following graph [some minor details about what I mean by graph elided]”. The same thing is happening with your quote from Seven Sketches: the finite graph with a single vertex and a single loop freely generates the infinite category corresponding to the monoid of natural numbers.

view this post on Zulip Paul Lang (Feb 17 2025 at 13:12):

I see. That makes sense. Thanks Kevin!