Skip to main content

Section 5.22 Session 24: Uniqueness of products and definition of sum, Part 2

I left of at the last exercise, which has both an “easy part” and a “hard part”. Let’s see what kind of progress I can make.

Example 5.22.1. Exercise 3:.

Reread Section 5 of Session 15...
Solution.
As a means of exploring this, I booted up my Python interpreter again. The code accompanying this week’s Exercise can be found here
 1 
github.com/rruff82/LS-Categories/blob/main/assets/notebooks/ls-ses24.ipynb
.
For part (a), I took a naive approach to constructing \(X^{\circlearrowright \alpha} + Y^{\circlearrowright \beta}\) by basically concatenating the lists of generators and relations. I used Python’s built in hash method to construct unique names for the nodes in \(X+Y\text{,}\) then translated the original relations to use the new names.
To check that the sum was indeed this simple, I used the reconstruct_endomap method I built previously to confirm that the presentation produced a graph with the expected shape. Specifically, the following graph \((X+Y)^{\circlearrowright \gamma}\) can be thought of as having 8 generators \(a,b,c,d,p,q,m,z\) and 8 relations \(\gamma^5 a = \gamma^2 a\text{,}\) \(\gamma b = \gamma^2 a\text{,}\) \(\gamma c = \gamma^3 a\text{,}\) \(\gamma^2 d = d\text{,}\) \(\gamma^6 p = \gamma^2 p\text{,}\) \(\gamma q = \gamma p\text{,}\) \(\gamma^2 m = m\text{,}\) and \(\gamma^4 z = \gamma z\text{:}\)
Sum of endomaps on X and Y
That basically concludes Part (a).
For part (b), I tried to cheat. I used the graph_product function I wrote previously, applied it to the graphs of \(X\) and \(Y\text{,}\) then passed the output into my previously coded make_presentation method. It resulted in a crazy-looking presentation with 59 generators that made little sense at all.
Under closer scrutiny, I noticed that my graph_product wasn’t behaving as expected. Specifically, it failed to preserve commutivity of \(2 \times D\) and \(D \times 2\text{.}\) In an effort to fix this, I ended up writing a graph_sum method using matrix operations and used that as a foundation for rewriting my graph_product. After confirming that it fixed the glitch, I tried again.
With my corrections in place, the resulting product \(X^{\circlearrowright \alpha} \times Y^{\circlearrowright \beta}\) had 9 generators and 9 relations:
{'generators': [0, 1, 12, 13, 14, 25, 26, 27, 38], 'relations': [((0, 6), (0, 2)), ((1, 1), (0, 1)), ((12, 4), (12, 1)), ((13, 1), (0, 1)), ((14, 1), (0, 1)), ((25, 1), (12, 1)), ((26, 1), (0, 1)), ((27, 1), (0, 1)), ((38, 1), (12, 1))]}
Going from 8 generators to 9 seems to make a lot more sense than having 59 generators. It also seems to support a hypothesis I had about a connection between the generators and the eigenvalues of the adjacency matrix. However, this make_presentation that I implemented earlier was designed specifically for “endomaps”. It’s entirely plausible that there’s still another error in my code to find.
In fact, I’m quite certain there’s still a problem because I’m getting “null” presentations for 4 out of my 6 sub-products. I think it’s more likely that I’m looking for a presentation with 16 generators, each one being a product between the generators of \(X^{\circlearrowright \alpha}\) and \(Y^{\circlearrowright \beta}\text{.}\) The reason my algorithm fails is that it can’t identify a generator for shapes like \(C_2 \times C_2\) is that there isn’t a one-to-one correspondence between “dots” and “arrows” unless I somehow expand it to \(C_4\) first.
Presently, my guess that the only two shapes in the product for which my make_presentation produces “something” are the two products where both shapes in the product have “tails”. Perhaps what the remaining shapes have in common is that the map from the initial object to that shape is unique.
If the generators of my product are, in fact, the products of the generators, than maybe the key to finding the relations lies in the result of Session 21 Exercise 2. If the product of two cycles with lengths \(m,n\) is a cycle of length \(lcm(m,n)\text{,}\) maybe we can use that information to help find the corresponding relations.
In this case, it works nicely because there’s a one-to-one relationship between our generators and the relations, so the product would have both 16 generators and 16 relations.
Each generator (which has a relation) could have that relation written in the the form \(\gamma^a g_n = \gamma^b g_n\) for some \(a,b \in \mathbb{N}\) such that \(a > b\text{,}\) and \(a - b\) would give the cycle length. In addition, this number \(b\) defines the “tail length” associated with that shape. Based on the fact that my generators seem to disappear, I’d guess that the tail length of the product is the minimum of the two shapes being multiplied, but I’m not really sure.
I’m a little unsatisfied with that result, but I think I’ve explored it enough to keep moving forward.