Teaching category theory to engineers (part 4)

I’ll start off with a clarification. My students are engineers in the sense that they are PhD students and postdoc in control theory. So they’re very well acquainted with certain sections of modern mathematics: dynamical systems, optimization, some differential geometry, but not so much abstract algebra. The experience with linear algebra is interesting, because it seems like they know some advanced stuff in the matrix algebra side, but the abstract vector space side is hit-and-miss. So motivation for them is not exactly a problem with getting them to believe that abstract math is useful, or even that category theory is useful. The problem is more about convincing them each lecture that it’s worth coming back to the next one, or that convincing them that they’ll get to the useful stage before the heat death of the universe.

I’ve been feeling both that I’m going too fast and too slow. In four weeks, I’ve barely gone through the definition of category and the definition of functor. Part of that is due to the fact that I only scheduled one hour per week of lecture time. This simply is not enough total time. The other part is that I didn’t only define those two terms obviously, I gave several examples. Ultimately, I think the pacing is going ok. I asked them and they mostly either said the pace was perfect because it’s still a lot to absorb, or they said they were itching to get to juicier parts. So today, I feel like I sped up somewhat. I didn’t get to the definition of natural transformation yet, though I hinted at it. I just focused on giving more examples.

I started with the covariant powerset functor. I had them compute a specific instance of it on the ceiling function. I had hinted that this was a useful functor, and they didn’t believe me, so I did actually define endofunctor coalgebra for them, and explained how a P-coalgebra is a “transition system” and certain theoretical computer scientists love that.

Then the rest of the time I used to throw them in the deep end of layering abstractions, or at least as far as I could get them with knowing so few definitions.

1. A graph is a functor from the category with two objects and two parallel non-trivial arrows. I defined graph homomorphism and even wrote it as commutative squares, but didn’t define natural transformation yet.
2. The path category construction can be extended to graph maps, thus inducing a functor between the path categories.
3. This construction itself defines the morphism part of a functor from the category of graphs to the category of categories.

I think they generally understood this. I explained each one a lot, and in several ways, especially the first one. Also one student came up after and asked for more explanation about how the category of graphs has functors for objects, but Cat has functors for morphisms, and Path was somehow also a functor. I pulled back the curtain on higher categories a little bit and she actually said it helped her understand it a lot better.

After all theses graph-related functors just getting more and more abstract, I gave them an example of a database schema straight out of Seven Sketches. I hope this helped nail things down a bit. At the very end I only had time to hand-wave the last example. Aaron Ames in his thesis used category theory to talk about hybrid systems. I basically just told them in mid-air that his definition of hybrid system is that the discrete part is a database schema, and the continuous part makes up an instance. I’ll unpack that idea in detail next time, and then get into natural transformations.

Teaching category theory to engineers (part 3)