5 ms·
Sorry, this is the third part of a series. I think I said what those were in the first part but I'm not sure dom and cod are the domain and codomain of a morph
by philzook 6y ago
Sorry, this is the third part of a series. I think I said what those were in the first part but I'm not sure
dom and cod are the domain and codomain of a morphism. They are functions that given a morphism will return the object at the head or tail of the morphism.
I don't think that these articles are a very good self contained explanation of category theory. At the moment, I've been aiming at a supplement written in concrete python to something more thorough.
- philzook 6y agoFrom a programming persepctive, I could recommend Bartosz Milewski's series https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/ https://bartoszmilewski.com/2014/10/28/category-theory-for-p... RydeHeard and Burstall - http://www.cs.man.ac.uk/~david/categories/book/book.pdf http://www.cs.man.ac.uk/~david/categories/book/book.pdf Milewski, Fong, and Spivak's course - http://brendanfong.com/programmingcats.html http://brendanfong.com/programmingcats.html From a mathematical perspective: MacLane, Awodey's book, Conceptual Mathematics by Lawvere and Schanuel.
- heavenlyblue 6y agoWhat’s the point of using the short names? You could call them domain and codomain and then everyone could Google them
- tom_mellior 6y agoMore generally, I think all the naming could be improved. Why not write out "domain" and "codomain"? Why abbreviate "identity" as "idd", is that standard anywhere? Why use "mplus" and "mzero"? The latter is as in Haskell, I believe, but there they must do it that way because they can't overload the identifiers. Inside Python classes you don't have that restriction.
- philzook 6y agoA good point. If my goal is educational (and it 2/3 is), these stupid short names are a huge oversight. I honestly didn't think about it much. I think I started from known Haskell names, some conventions that I may have absorbed from catlab.jl and other places, and some unthoughtful accidents. I really really wanted id to be the identity, but I'm pretty sure it's a python keyword. I added a d and vowed to never speak of it again. Ever written a program about schools and had to use the variable Klass? I don't feel too bad about mplus and mzero. It's still pretty clear that they are something like plus and zero, but the m gives you pause. And it should, since in one case mplus is in fact multiplication. If this was rolled out into a library maybe I'd have both long and short names? I'd never want a library to have only long names for really common things. cod and dom don't actually give me a seconds pause. I like them having the same length too. Makes code prettier and easier to read. I also intend to replace some things with operators which would be even more inscrutable to a newcomer. @ has to be compose for example (to mimic numpy).
- tom_mellior 6y ago> I really really wanted id to be the identity, but I'm pretty sure it's a python keyword. It's a built-in function, but you can overload it within a scope you control without problems: >>> id <built-in function id> >>> id = 7 >>> id 7 > And it should, since in one case mplus is in fact multiplication. Good point! I take this part back. As for having identifiers the same length, I know the urge, but usually find the superficial "elegance" it's not worth it.
- occamrazor 6y agoIn CS the tradition is to use longer and more descriptive names, in maths instead short and generic ones. I guess that on a blackboard it’s more useful to maximize information density, in a text editor or an IDE instead clarity is more important. Even different programming languages have different conventions (short identifiers fir C and Fortran, long ones for Java and C#), which reflect the habits and preferences of their creators and users.