How do we reconcile these two definitions of categorical cones?

380 Views Asked by At

Bartosz Milewski describes two definitions of cones, as used in the definition of limits. First, we have the more direct, pointwise approach:

Choose an index category $I$ and a functor $D : I \to C$. A cone is an object $c \in C$ called the apex together with a family of morphisms $\alpha_i : c \to D \, i$ (for each $i \in I$) such that if $f : i \to j$ is an arrow in $I$ then $\alpha_j = D \, f \circ \alpha_i$.

We observe that we can replace this with a simpler definition based on natural transformations:

Choose an index category $I$ and a functor $D : I \to C$. A cone is a natural transformation $\alpha : \Delta_c \to D$, where $\Delta_c : I \to C$ is a constant functor.

(The general source for this is videos 1.2, 2.1, and 2.2 in the Category Theory II playlist; I don’t have an exact timestamp.)

This makes sense to me in the case where $I$ is non-empty: the naturality condition in the second definition is exactly equivalent to the commutativity conditions in the first definition.

But what happens when the index category $I$ has no objects, and so $D : I \to C$ is the vacuous/absurd functor? Then, our first definition asks us to choose an apex $c$ together with no morphisms, so that a cone is just an object in $C$. All good. Our second definition requires us to choose a constant functor from $I$ to $C$—we can do so; this will also be the absurd functor. But then we have not specified any object in $C$! What happens to the apex?

This distinction is of course necessary, because we need $I = \mathbf 0$ to talk about terminal objects as limits.

In a YouTube comment about this question, Bartosz says:

This is one of these math tricks. A constant functor always produces just one object no matter how many objects there are in the source category. So it's natural to assume that it does the same with an empty category. That's the best explanation I could come up with off the top of my head. See, for instance, https://ncatlab.org/nlab/show/terminal+object

Frankly, I'm nor really happy with this answer, and you may notice that I did a little double take during the lecture. Feel free to post a question on stack overload.

(…so here I am!)

Along this road: nLab says that “A terminal object may also be viewed as a limit over the empty diagram”, but nLab’s definition of cones over a diagram is too complicated for me to determine whether it is equivalent to the first definition, the second definition, or neither. (It requires constructing the category $\operatorname{cone}(J)$ of cones over $J$ as a cocomma category, and I don’t yet understand what comma and cocomma categories are—and would prefer not to have to to answer this question. All in due time.)

The natural transformation version of the definition seems much more “categorical”; how do we resolve the incongruity when the index category is empty?

2

There are 2 best solutions below

4
On BEST ANSWER

Great question! I had never noticed how often people misstate the natural transformation definition of cones before. Happily, it's given correctly in the nLab article you linked. Given $D:I\to C$, a cone over $D$ is given by an extension of $D$ to the cone category of I-but there's no need to worry about what a cocomma object is. By definition, an extension of $D$ to $\mathrm{cone}(I)$ is a pair $(c,\alpha:\Delta_c\to D)$. Here $\Delta_c$ is defined, not as the constant functor at $c$-which does not make sense when $I$ is empty-but as the composition $i_c\circ p_I$, where $p_I: I\to *$ is the unique functor from $I$ to the category with one object and one morphism and $i_c:*\to C$ is the inclusion of $c$.

This resolves the issue of $I=\emptyset$. While in that case $\Delta_c$ is always the empty functor, the data of a cone also specifies $c$ separately. The reason, as may now be clear, that people usually aren't this precise is that $\Delta_c$ determines $c$ whenever $I$ is nonempty. But as you note, cones over empty diagrams are extremely important, so it's not an innocent simplification!

2
On

Arguably, the error here is in the definition of constant functor. For example, look at nlab's definition of constant function

... a constant function from $S$ to $T$ with value $x$ is the function $f$ defined by $$f(a) = x $$ for every element $a$ of $S$.

Note, in particular that the value of $x$ is part of the type. This does not define "constant function", it defines "constant function with value $x$".

Even when $S$ is the empty set, we still remember the unique value that a constant function with value $x$ takes — that value is $x$.

This is similar to the issue in the construction of Set where we might want to express elements of $\hom(S,T)$ as being particular subsets of $S \times T$; that is, by the graph of the function. However, graphs don't remember the codomain; so if we want to talk about general arrows of Set, we need to bundle the codomain together with the graph. That is, an arrow of Set is a pair $(\Gamma, T)$ where $\Gamma$ is the graph of a function $S \to T$.

The same thing goes here; if we want to talk about general constant functions, we should bundle the value together with the function. A constant function should thus be a pair $(x, f)$ such that $f$ is constant with value $x$.

Doing so correctly remembers the value, even in the case where the domain is empty.


I argue the definition of constant functor should be the same way; that the constant is part of the type. Even when the domain of the functor is empty, the "correct" definition of constant functor still remembers what value it takes.

Using the right notion of constant functor should give the correct notion of cone even for empty diagrams.