Applied category theory in chemistry, computing, and social networks [pdf]
ams.org
ams.org
[1] https://topos.site/ [2] https://arxiv.org/abs/1803.05316
https://www.amazon.com/Joy-Abstraction-Exploration-Category-...
Then there's of course the classic introduction Conceptual Mathematics by Lawvere and Schanuel.
https://www.amazon.com/Conceptual-Mathematics-First-Introduc...
This is key. Sure category theoretic abstractions are useful as a common language. Lot's of theorems are applicable in many domains.
The hard thing is understanding all this stuff and mapping it into your domain.
To me it seems a lot like the crypto and web 3.0 promises of "soon there will be all of these amazing applications"... and then there aren't any.
Also, all of the examples of CT I've seen are applicable only to pure functional languages like Haskell, which seems to limit their practical utility.
edit: This question is genuine. There are only abstract concepts included in the video and wiki, as deep as I can see.
My interpretation of "solving a real world problem" means that it can't be infinitely abstract, and must be a relatively good solution, compared to other options. I only see, from my dumb perspective, extreme abstracts.
I'm not being combative. I just don't understand.
In time, that's correct. At the moment, I disagree.
I usually program in C++ or php, but I do think in monads / functors / applicatives quite often. I then use whatever features of the language I have at my disposal to “encode” my thinking at an appropriate level of abstraction. What level of abstraction that is depends not only on the language, but also how efficient and “communicable” I want my code to be. I don’t mind expanding the `map` of a functor into an explicit for loop, if my junior colleague can more easily deal with it.
In fact, at this point, with functional programming patterns having become so pervasive, most people including beginners have no problem with the concept of functors, and “mapping” functions on things. Monads still have that aura around them, but really, any time you write a line of code that reuses the result of a previous line of code and checks for something, you probably have a monad hiding in there, and “exposing” it might make it easier to factor out your code or find an elegant API.
- the group of people who don't see the relevance of mathematics "in the real world", and expect any a-ha moment to have come to them by magic already, and;
- the other group.
Differential Equations Statistics / Stochastic Processes Discrete Math / Algorithms / Logic Solver
You do not need CT for all this stuff.
Grothendieck needed CT - ist Algebraic Geometry useful?
I've read the paper. They list many useful applications. CT doesn't seem really necessary for each of them but it looks like CT is (could be) helpful.
It is just very hard to create non-trivial general theories in sich „Applied“ fields, Functional Analysis alone is not very exciting. For an example see for example the work or Hairer (stochastic differential equations) or Costello (QFT).
This is wild stuff:
https://people.math.umass.edu/~mirkovic/0.SEMINARS/1.QFT/C.C...
funny names: a Leonard Cohen writing about an Costello (but Kevin Costello not Elvis Costello)
> Statebox is blending an ACT approach to Petri nets together with blockchain technology to develop a technology stack based on a visual programming language. In addition, they have built a software engine for compositional game-theoretic modeling, a finite state machine oracle.
Hmm.
More seriously:
> Structured cospans of Petri nets were implemented in the software package Julia to develop an SIR model that is compositional in the sense that various cities can each have their own model that can be connected together to form a composite SIR model
SIR is the most common way of modelling infectious diseases. Having said that though - there are plenty of SIR models that don't require category theory.
There was another talk where IIRC Edward Kmett dualizes divide and conquer algorithms to derive a generic bucket sort that works on general algebraic data types[1].
These are generic concepts. Haskell is just convenient to express them in. In some sense, obeying functor or monad laws just means you'll have a "clean", predictable design, for example. The language doesn't need special support; you just need to check whether your code is composable in a sensible way.
There's no such thing as a theorem that can only be proven with category theory, because whatever specific thing you're applying category theory to already has all of the properties that would make the theorem true without category theory being involved - if it didn't, you wouldn't be able to treat it as if it was a category. Categories are not the kind of mathematical invention that, for example, ordinary differential equations or matrices are.
In Grothendieck's early work on abelian categories, categories are themselves the objects of mathematical study, and nontrivial results about them are established.
… makes it incomprehensible to experts in the field and laymen alike!
But sometimes it feels like Category Theory is rebuilding the world and there are genuine theorems.
Epilogue: Theorems in Category Theory
I think the point of category theory, especially applied category theory, is recognizing what can be further abstracted as an arrow and an object. This turns something that originally is complex and has no apparent structure into a simple dot and arrow, again. Then rinse and repeat.
For example, you can take a for loop that applies a function to a list and then creates a new list. You can't "easily" add another for loop that then applies a second transformation. But if you recognize the functor from the category of types to the category of types, then you can formulate your 2 composed for loops as `list.map(f1 | f2)`, and everything is "trivial" arrows and objects again.
Turn that into a function that returns a list, and you want to concatenate the result. "Annoying" to write, you have to flatten your list. Recognize the monad, back to a simple composition of two morphisms, even though the morphisms encapsulate a lot.
Learning and applying CT I think is recognizing which things can be conceptualized as a morphism, which then magically makes things appear "simple." Yet it is only simple if you have done that recognition work, and more advanced concepts in CT are there to assist you.
This is quite unconvincing.
Easy solution 1: add a second loop which takes the first loop's output and transforms it with f2.
Easy solution 2: realise you are doing one transform after another and replace out.add(f1(x)) with out.add(f2(f1(x)).
It sounds glaringly obvious in the cases where the abstraction is well understood Mapping on lists, on trees, on Maybe, on Result are all well known at this point, because most APIs offer it. Less obvious is the fact that this applies to say, a serial interface, sensor readings, futures.
If you can then express the concept of a functor in the programming language itself, you can start writing code that only relies on the fact that something is a functor. And then pass it a list, a serial interface, futures, futures of serial interfaces, etc…
For example, you could potentially find use in expressing your above code as:
out = makeMapped(out, [f1, f2])
Now I can just pile 18 more functions defined in a config file without having to write it out.
out = makeMapped(out, configFile.createFunctions())
I’m not saying you need category theory for this, the same way you don’t need algebra every time you add two numbers, but it makes it easier to see these patterns.
I have trouble finding good “practical” examples, because you can use either functors, that every experienced programmer already knows intuitively so well that the concept is ingrained. If you bring up monads, people often react viscerally.
In practice, I often just take the time to write out monads without even mentioning the word or concept, and refactor code so that it leverages that underlying structure, and that usually makes things become apparent. Monads are a really good structure to cut down on absurd complexity for anything dealing with state and concurrency, and turn it into an elegant problem.sequence(step1, step2, step3, step4) formulation.
The short answer is that a category also satisfies two rules: every object has an arrow to itself (identity) and if there are two arrows (a->b) and (b->c) there is an arrow (a->c) (associativity).
Other abstractions such as functors (mappings between categories) are built upon this relatively simple foundation. You can also think about categories of categories (they can be considered an object, after all!), and so on and so forth.
Some complain about the generality of Category Theory ('It is a theory about everything and nothing!'), but its generality makes it compelling for some for study.
Well, that's because that's basically it, lol.
But I get your sentiment and, sure, there's a lot of things where this could be applied and that hasn't happened already. It's definitely a field with a prolific future, though. I've personally applied many ideas I got from there into my smallish ventures with good results.
But to me, the value in ACT is actually learning how "simple" some of the other fields could be, because it allows me to communicate with non-software engineers, and actually have them contribute to software.
I did a lot of work with state machines as composable abstractions for concurrency and flow control, and mechanical engineers were able to find some really subtle say, race conditions, just by pointing out "hey, isn't there an arrow from this to this, if the limit switch catches early?"
https://mathoverflow.net/questions/12511/what-is-yonedas-lem...
"Each of the steps is fairly compelling, except perhaps the second one, which rests on the Yoneda Lemma"
see "Kan Extensions for Program Optimisation"
I think it is a property of human cognition that if we draw an arrow from a to b, and one from b to c, that there is some kind of relation between a to c as well.
What this means concretely is that if I can draw my problem, in my domain, as a diagram with boxes and arrows, there is a reasonable chance that you can actually understand it, and actually contribute to it. Similarly, seeing diagrams from your problem domain is often sometimes I can relate to my design patterns and software architecture foundations, and I might be able to ask quite pointed questions when trying to say, build a mathematical model or build some supply chain software. Questions like “ok, but, is there an arrow from here to here?” and the answer “oh yes, that happens when we actually replenish the inventory by doing X, I forgot about that part”.
Another thing I found people do with CT is that they use it as a toolbox of abstractions that they can try to fit to a problem. Say, “oh, is there maybe a functor from petri nets to databases? ok, there is, but it’s kind of useless. Does this formulation actually work as a monad?” This is useful for finding elegant APIs to problems, say things like optics (lenses, etc…).
Only point of category theory starts when you go higher than that and deal with more abstract and generalizable things e.g monads(which again is used in other theories), bigger infinities, ordering of infinities etc.