Category Theory
Zulip Server
Archive

You're reading the public-facing archive of the Category Theory Zulip server.
To join the server you need an invite. Anybody can get an invite by contacting Matteo Capucci at name dot surname at gmail dot com.
For all things related to this archive refer to the same person.

Stream: event: ACT20

Topic: July 8: Bob Coecke et al.'s talk

Paolo Perrone (Jul 02 2020 at 02:12):

Hello all! This is the thread of discussion for the talk of Giovanni de Felice, Alexis Toumi and Bob Coecke, "DisCoPy: Monoidal Categories in Python".
Date and time: Wednesday July 8, 11:40 UTC.
Zoom meeting: https://mit.zoom.us/j/7055345747
YouTube live stream: https://www.youtube.com/watch?v=AaaoUxUx-SQ&list=PLCOXjXDLt3pZDHGYOIqtg1m1lLOURjl1Q

Paolo Perrone (Jul 08 2020 at 11:30):

10 minutes!

Alexis Toumi (Jul 08 2020 at 12:07):

Here are my slides for the talk! presentation.pdf

Alexis Toumi (Jul 08 2020 at 12:08):

Also a link to the github repo for DisCoPy: https://github.com/oxford-quantum-group/discopy

Filip Buric (Jul 08 2020 at 12:09):

Fun stuff! I suppose there's plenty of work in hand-drawn circuit recognition? It would be helpful I suppose to ask people to stick close enough to a drawing convention, albeit at a cost of creativity :)

Alexis Toumi (Jul 08 2020 at 12:24):

There seems to be some papers on circuit recognition for the particular case of electric circuits, but I'm sure no-one has tried doing it with arbitrary monoidal categories yet! As for drawing convention, one can hope that with sufficient training data, a machine learning algorithm would be able to adapt to different conventions.

Alexis Toumi (Jul 08 2020 at 12:33):

Here is a link to the reference for normal forms of string diagrams: https://arxiv.org/abs/1804.07832

Filip Buric (Jul 08 2020 at 12:33):

Cool! Sure, but it's also a question of finding the appropriate architecture, hyperparameter space and search procedure etc. More data doesn't always help. One can get quite robust recognition of shapes, but there will of course be limits and edge cases. Even for hand-drawn digits the performance is <100% (mostly due to human ambiguity I believe). But maybe it's easier with diagrams. I was just thinking of edge case like e.g. where nodes are drawn as large circles and they would be recognized as small loops. Still, seems doable :)

Alexis Toumi (Jul 08 2020 at 12:35):

Yep, for sure more data isn't gonna solve everything, but a minimum of training data should be enough to recognise different lighting conditions, hand writings, etc.

Filip Buric (Jul 08 2020 at 12:35):

Thanks for the ref! I sometimes work with biochemical networks graphically so this looks quite interesting!

Filip Buric (Jul 08 2020 at 12:35):

Oh absolutely, yes.

Aleks Kissinger (Jul 08 2020 at 12:36):

I'll put this here, because it might have gotten lost in Zoom: @Alexis Toumi @Giovanni de Felice Did you guys play with hooking this up to pyzx already? It would be nice, especially for ZX-calculus tutorials to have monoidal-category type notation for creating ZX-diagrams from generators . Currently, there is only QASM and friends, as well as a sortof hack called SQASM (spider-QASM) which does some automatic post-selection + spider fusion.

Alexis Toumi (Jul 08 2020 at 12:37):

Filip Buric said:

Cool! Sure, but it's also a question of finding the appropriate architecture, hyperparameter space and search procedure etc. More data doesn't always help. One can get quite robust recognition of shapes, but there will of course be limits and edge cases. Even for hand-drawn digits the performance is <100% (mostly due to human ambiguity I believe). But maybe it's easier with diagrams. I was just thinking of edge case like e.g. where nodes are drawn as large circles and they would be recognized as small loops. Still, seems doable :)

I think monoidal categories and Joyal-Street's work on the geometry of tensor calculus (http://www.math.mq.edu.au/~street/PlanarDiags.pdf) should help tremendously for designing the architecture of a diagram recognition machine.

Alexis Toumi (Jul 08 2020 at 12:38):

@Aleks Kissinger for now, you can get from DisCoPy diagrams to PyZX by going through pytket, but it works for circuits only, not for arbitrary ZX diagrams

Alexis Toumi (Jul 08 2020 at 12:39):

I remember we started working on a direct translation, but we had a hard time figuring out what were the input and output types for ZX diagrams

Alexis Toumi (Jul 08 2020 at 12:40):

also, it would be a lot better if we kept track of planar positions for the diagrams, so that a tensor product would actually look like the two diagrams side by side

Aleks Kissinger (Jul 08 2020 at 13:08):

the main type in PyZX is just an undirected graph with a bit of extra data. The extra data consists of: typing (Z, X, H, boundary), phases, lists of boundary-typed nodes that should be treated as inputs and outputs, and numbers "row" and "qubit" assigned to each node. The last piece of data pretty much only effects drawing (with a couple of exceptions), so for most purposes, you can read "row" and "qubit" as "X coordinate" and "Y coordinate".

Jules Hedges (Jul 08 2020 at 14:03):

I have a question, I think this was sort of implicit in the talk. You talked about defining a diagram by specifying it as a term in the language of monoidal categories (which in my experience gets quite painful very quickly), and then by inference from the diagram. What about things in between? For a specific example, take the DSL from my talk. There is a compiler that turns that code into the language of monoidal categories (specifically by foliation, so each line of code turns into a slice of the diagram containing one nontrivial node plus a lot of plumbing). I imagine this would be quite easy to build on top of your libraries, is that right?

Paolo Perrone (Jul 08 2020 at 16:11):

Here's the video!
https://www.youtube.com/watch?v=kPar2nQVFnY&list=PLCOXjXDLt3pYot9VNdLlZqGajHyZUywdI

Alexis Toumi (Jul 09 2020 at 10:04):

@Jules Hedges Indeed writing down terms in the language of monoidal categories by hand does get very painful very quick! As you mention, we use the diagram data structure for discopy (pre-monoidal diagrams with one node per layer) as a kind of low-level language that we compile into. It would be very easy to write a higher-level DSL that then compiles down to diagram, to some extent this is what a pregroup grammar really is.

Giovanni de Felice (Jul 09 2020 at 11:00):

Also I should mention that in order to define a category in discopy it is enough to subclass Box and override the methods for identity, composition and tensor. So for instance these could output the haskell code for composition and tensor of open games. Then given any Diagram instance (seen syntactically, i.e. a morphism in the free monoidal category) you can define a functor and you get for any diagram the corresponding open game written in haskell.
Here's an example defining monoids as a subclass of Box: https://github.com/oxford-quantum-group/discopy/blob/master/notebooks/monoid-delooping.ipynb

Jules Hedges (Jul 09 2020 at 11:07):

Alexis Toumi said:

Jules Hedges Indeed writing down terms in the language of monoidal categories by hand does get very painful very quick! As you mention, we use the diagram data structure for discopy (pre-monoidal diagrams with one node per layer) as a kind of low-level language that we compile into. It would be very easy to write a higher-level DSL that then compiles down to diagram, to some extent this is what a pregroup grammar really is.

Does Python support this kind of metaprogramming nicely, embedding a DSL with its own syntax? (This is part of me trying to understand the benefits of DisCoPy vs Catlab)

James Fairbanks (Jul 09 2020 at 11:23):

Python does not support meta programming

James Fairbanks (Jul 09 2020 at 11:26):

Of course you could put the DSL code in a string literal and then parse it by hand.

Alexis Toumi (Jul 09 2020 at 11:54):

Python doesn't have the kind of meta programming that Julia implements, but in practice you can get similar results using higher-order constructions like decorators. A beautiful example is automatic differentiation and just-in-time compilation with jax https://github.com/google/jax

Alexis Toumi (Jul 09 2020 at 11:57):

So for example you could implement something similar to Catlab's natural syntax for cartesian morphisms with a decorator, so that it takes a python-defined function and compiles it down to a DisCoPy diagram. We haven't done that yet because we mainly focused on non-cartesian settings like quantum and linguistics for now.

James Fairbanks (Jul 09 2020 at 12:13):

I don’t think that reflects an accurate understanding of how macros work. Jules, I’m happy to work with you and Toby on how to get open games into Catlab.

Jules Hedges (Jul 09 2020 at 12:14):

Thanks both! This is helpful

Alexis Toumi (Jul 09 2020 at 12:42):

James Fairbanks said:

I don’t think that reflects an accurate understanding of how macros work.

https://www.youtube.com/watch?v=pWdd6_ZxX8c

Toby Smithe (Jul 09 2020 at 12:50):

James Fairbanks said:

I don’t think that reflects an accurate understanding of how macros work. Jules, I’m happy to work with you and Toby on how to get open games into Catlab.

Open secret: in a past life, I wrote Python bindings for a GPGPU linear algebra library... http://viennacl.sourceforge.net/pyviennacl/doc/