Live CEOing Ep 719: Language Design Review of Hypergraph Paclet

Okay. Hi everyone. This is a different kind of meeting because what we're looking at is some Wolfram Institute work on a packlet for hypergraph. Well, hypergraphs in general. And so Nick was going to show how this works. And this is the first time I'm seeing this. So there's a hypergraph object.

Yeah. So basically the idea is to show some. First of all, it's the packlet for hypergraphs. So there is a hypergraph object. And hypergraph object contains some edges and vertices. Right. Some additions.

It automatically renders like a graph does.

Yeah, it's like a first class citizen. And it has a red border.

How stylish.

Graphs have like some purplish trees have greenish. And hypergraphs are red for some reason. Okay, so one addition that we, I.

Would argue, by the way, in terms of that theming, you know, the physics project has traditionally been a purple themed thing, so we might consider that. But that's a.

Well, graph is already purple.

Right? I know, I know, I know. So let's see what purple it is. It's very purple. Well, we should let the design group maybe have a suggestion about this. Okay. All right. So that hypergraph anyway is an ordered hypogram hypergraph, is that correct?

This actually is this, this is actually we are dealing with unordered by default. So one thing I'll show a bit later that we have like an additional annotation to each edge, which is its symmetry. And by default it's an ordered. And actually you can show it now. Why not? Right. So we can annotate each edge by asymmetries.

I mean, I, I, you know, one of the things that we learned in the physics project is the value of having ordered hypergraph structures.

The other case also didn't think it.

What's that?

I think covers can, I think covers can defend this position more clearly because I was also kind of against unordered by default first.

I think it's a mistake. I just think a list is not unordered by default. If we had a set object that was unordered by default, I would be more inclined to say that this is Right. But it's a list, it's not unordered.

Yeah, so, so let me jump in in a second. So the reason, the reason why we want unordered by default, I mean, this is just a choice. There's no, there's not so much of a conceptual preference to unordered or ordered is more that we need a control on the symmetry of the edge very explicitly. So we could make them ordered by default and then they are like the hypergraphs in the physics project. There's no difference there. I mean, it's just a matter of what is default. I mean, that's just an option. But what here is that we are giving a very explicit treatment of symmetry.

We.

We are, I guess.

So it makes more sense to have them unordered by default with no symmetry, and then to say as the annotation, what symmetry you want to have. Because. Because what we've got, if you remember, you know, how permutations work, for example, we can specify a. Right, yes, exactly like that.

Yeah, yeah, yeah, yeah. But I think what you said is exactly what we have. I think you say that they should be unordered by the.

I'm sorry, I'm sorry. They should be, they should be. By default. They should have no symmetry by default. If you want them to have symmetry, put in a symmetry.

Yeah, yeah, yeah, yeah. That's. It's just a matter of what is the default option.

No, I understand, but by no symmetry, I mean that 1, 2, 3 is equivalent to nothing else.

Sure, yeah, yeah.

Okay.

This is the null symmetry because it's ordered.

Yeah.

And we interpret or represent the symmetry by just like generators for the permutation group.

Fine. But that's what I'm just saying. I think it's a no brainer thing that the default should be that there isn't any symmetry. And if you specify a symmetry. Great. Then you have a symmetry.

Yeah. I mean here the whole debate is simply whether you take lists or you take multi sets as your default.

I know, but we have lists. Yeah, yeah. Lists are the thing that are, you know, and plus they turn out to have worked rather well in the physics project. So I think we should, you know, we shouldn't go against that. Yeah, this is a minor thing.

Yeah, it's a minor. It's just a choice. It's not, it's not.

Right. So that's an easy thing to fix. All right. Is it the right thing to use an annotation for the symmetry or is that actually more of a serious construct? I mean, in other words, we don't have the notion of a list, you know, in the language. We don't have the notion of a list with a certain symmetry. But we could have, we certainly have the notion of a structured array with certain symmetry. Yeah.

And like tensor symmetries, symmetric and asymmetric.

Right. So I think we should be using some. Go ahead.

But here, I don't know, it's just much easier for now just store every additional concept, like an option as an annotation. Just model graphs as much as possible. It's like I support a bunch of those annotations.

That's a fair point, by the way. Jonathan. Hello, Jonathan. You know, do feel free to jump in.

Yeah, sorry I tried earlier, but I think we moved on, so. It's okay. I'll jump in again if it's relevant.

Well, did you want to re. Jump to whatever you were jumping to before?

I mean, I just had a couple. I mean, I broadly agree that particularly if you're representing symmetries as kind of subgroups of the permutation group, then it makes sense to have no group structure as the default. Although to play devil's advocate a little bit, I do think there is something inherently a bit weird about the fact that you've got a nested list. The outermost list is, is orderless, but the innermost list is ordered by default. That's the, that's the one, the strongest defense I can see for this. For this.

Yeah, right. I mean, we've had that issue, you know, in, in everything in the physics project because we, because we are currently treating sort of hyper edges as being a big vat of hyper edges and not an ordered sequence of hyper edges. That's what we've got.

Right. I mean, so. Yeah, yeah. The only thing I can add to that is that. Yeah, so this is exactly as Nick says. This is precisely a problem that we run into when doing tensor algebra. So right now, for instance, in the symbolic representation of things like Riemann tensors and stuff, we essentially use the same structure that you've got either a list or a sparse array. And then there's. In that case, it's not an annotation, but it's just a kind of effectively a list of slot symmetries. And then you have to do complicated.

Butler, Portugal how are the slot symmetries stored?

So it's a list of rules. So effectively what's going on internally is it's modeled on what we did for findable from model proof, which the sort of hypergraph theorem prover where you say what's effectively going on? You sort of algebratize the whole thing so that the case of an orderless hyper edge or something is the case where the composition operator on the individual hyperveses is commute, you know, has a commutativity property. So you reduce everything to some algebraic axioms. And then so in the case of the tensor algebra stuff, it's. There's just a list of Algebraic axioms that say, you know, what the symmetries of the Riemann tensor are or whatever.

But how does. I should know this. But how does a structured array. We have symmetries for structured arrays, don't we, Nick? Do you know this?

Well, I only know that you.

For symbolic tensors to say it's structured.

Oh, I mean, no, I just want to show them to. So symmetric. What structure? There are different structures. Right. But for symbolic tensors, I know the like special symmetries like symmetric. Anti symmetric you can use.

Right, but we need to know how those are used because that should inform this. Because I mean, be nice to be able to say symmetric for. You know.

Now that may be like for. I was planning to do something like this for a representation for different representation. Right. Now we store edges as this incidence list of edges. Right. Like for graphs. But for graphs there's also multiple representations. You can store them as list of edges or you can store them as an adjacency matrix.

Yep.

And if I also will implement this additional representation as a hypermatrix, in this case, I can also annotate it with this kind of symbols and symmetries. So. But that's for the future.

We should let you go on here. Okay. So onward.

All right, so the focus of this packlet overall is to focus on more smaller hypergraphs. Right. It also supports what I was going to mention, like 0rt ages too. Right. And. And there is like. Because we focus on the small edges. A nice widget. Yeah. So you can draw a bunch of small hyper edges very easily now. There's a nice widget for that.

Yeah, yeah. Okay. As I think I said before, the fonts are wrong on the right. Just a small point.

No, I think I changed to a different font. Maybe again to a wrong one. But it's a different.

I mean just use the text font.

The text font.

You don't want to use a code font for that.

Well, maybe because it's. I think I use some kind of IO queer. I don't remember.

Don't use an absolute font. Just use the text font and you'll be fine. I think. And. There's probably a little bit of detail in this that could be improved, but this is still very cool.

Yeah, there's like a different modes of drawing edges. Like you can draw instead of selecting and then pressing a button, you can drag and drop them like this. And after you draw it, you can click copy it. Right now you have this object.

So if I say input form of that object. Wait a second. What Happens if I say input form of that object.

It's a hypergraph, Right. With a hyper edges, a list of vertices and a bunch of options with coordinates there.

Yeah, yeah. So you've got a direct analog of. What the heck is that?

It's a traditional form. Traditional form. Just showing the edges like this. Like it shows here. This is the traditional form.

Yeah, you're just sliding that by. That's a non trivial and somewhat interesting form. Why is it the right form? I mean, so every hyper edge looks like a permutation or something there. Well, it doesn't. It's not really a permutation.

I just replace. I just replace list.

I know, I can see. Is that. Is that a notation that anybody else uses for hypergraphs?

Maybe I can comment briefly that. So the brackets I think is just incidental there. I don't think we ever made a strong choice about that. But the use of the O, it's actually operational because we have hypergraph addition and it works exactly as it should algebraically, without annotation. So that's cool.

I mean you could then think of a graph as being, you know, some kind of sum like that of pairs.

Absolutely, that's. That's right. That's right.

And actually you can add.

Exactly. Yeah, that's the point.

Like this. It's like a direction.

You can add a hypergraph. But. But that's, you know, the atom one is the same as in both cases, which is not obviously the right thing. How would I do that? Adding it as two different hypergraphs where, you know, where for example, the eights are in common but the other. The other vertices are not. No.

Then this has to be implemented. Some disjoint union thing. We don't have a function for that. But it's going to be hypergraph disjointed union or something.

Yeah. Basically it operates like you expect, Stephen. It operates that the common vertices are sort of multi edge addition.

I see it. Right. Yeah, yeah.

And the spare ones are sort of partial addition over. Yeah.

So for a graph. Let's just write out for a second. For a graph written out as an edge list. Could you just do this for a second? Just make a random graph. That's very small random graph. Well, not that. Okay, fine. All right, now let's. Let's give the edge list. Okay, so right, so if I say join that thing to itself, then I'll just get double edges. Okay, fine. Okay. So that's the same thing that you're doing. That's fine. Okay, I get.

Yeah.

And maybe Maybe. Nick, it's a good point to comment on the embedding that is just temporary. At the moment we're using some graph embedding of the projected down hypergraph.

Yeah, I'm still using graph embedding underneath, nothing fancy. I just also add some dummy edges so that it looks like this. Like curved?

Yeah, that's cute. I like the way that it works with multi edges down below. Yeah.

I want to comment that the intention is the ones that look convex, right. Where, sorry, concave. The ones that look like spider web, that's kind of the intention so that you can have the lower order stuff, not get in the way of the higher order stuff. And so visually helpful. But at the moment it's just using the embedding. So some of them are, are concave and some of them are convex more or less randomly. But eventually we want to do our own embedding function for hypergraphs. So the way we're thinking is we're going to take hyper edges so that it's cheaper. We're going to take hyper edges to be always contained in a plane in principle, and then we're just going to orient the planes to display the least intersection and things like that. Eventually.

What did we do? I mean, so Max had a whole way of doing hypergraph visualization, particularly in 3D. I mean, Max spent a long time doing. Well, I, I know you have 3D I'm. But do you understand what Max did?

Well, for the 3D case, we spent.

A long, long time talking about. We had a whole crazy scheme, maybe Jonathan remembers, we had a whole crazy scheme with a bunch of optimizations.

It was generalized. Spring electrical was ultimately what it boiled down to.

But there was another thing for the surfaces, right?

It was spring electrical with surface tension. So the idea was you had spring forces between hyper edges. Sorry, between hypervtices, you had electrical, and you had electrical repulsion. And then within an individual hyper edge, you would have a kind of surface tension force that would try and minimize its area.

Okay, and is that different from what you're planning, Nick, or is that similar to what you're planning?

Oh, I'm not sure. Right now I'm doing something similar. For each edge, I also introduce some dummy vertex when I. And then I just. If I use graph embedding with some spring electrical, it also would like introduce some tension or whatever, right?

Yeah.

Because I mean, you can make sure edges.

Right? If you introduce enough additional edges, you've got a whole surface there. I mean, if you had essentially a triangulation of additional edges that would be like an approximation to a surface. You're introducing a single dummy vertex. But in principle I think these look really nice, at least at these sizes.

Introduce a single vertex for each edge and I also put like directed edges in both directions so that they curve and then I extract the edge embedding also and drop one of them.

That is a hat. But it's cool.

Yeah, I know.

Yeah.

And for the 3D I also apply because field curve is no longer works for the 3D case. I also apply some surface minimization there.

Why this will for a few steps.

I think it doesn't work for 3D, so it's kind of annoying. So it's like a polygon. And then I do some surface minimization so that it actually can.

We should. We should bulge a little bit. Ask a question about filled code. We can ask. Yeah. Okay. All right, so onward now.

Rules are the most interesting things. Rewriting, right? So I have a few examples. So rules now are also first class citizens. Now they have blue border. They're basically represented by input and output hypergraphs.

So.

So you can construct a rule by just its input form is like input hypergraph and an output hypergraph like this.

And the variables here are just numerical things. I mean there's no like in writing. In the physics project we tended to use X and Y and things. But could you have any symbols or any expressions?

Yeah, we'll go to that. So here is like left hand side, the hypergraph is unlabeled, right. So it's basically an unordered age. So it can orderlessly match against this one in all possible cases in all possible ways. And because it's not unlabeled, I'll get to it a little bit later. Basically for this easiest examples first, this can match against this one in three possible ways. You may say that you can construct this edge in three possible ways again. So basically applying a rule to hypergraph just produces a bunch of information in this association like an output hypergraph and some meta information that you can use maybe some for causality later.

Right.

So because now it's just not just like for the WUHA model case, it's not just a list of edges, but also some vertices. Rules can also introduce new vertices and just three vertices without any edges when remove vertices from the hypergraph as a part of rewriting. So in this case there's no new vertices and no deleted vertices. But if there are three vertices like this here, that wasn't part of the left hand side. Something More interesting could happen.

But I mean, a standard physics project rule can create new vertices, right?

Well, only Raptor wrapped in. In an edge. It can be. It can't create like three vertices because there's no. There wasn't an idea of a hypergraph as a sum, just like a graph with no edges, for example, but a single vertex. Right. You wouldn't make this with a hypergraph.

How is a free vertex different to a. To a hyper edge with a single element?

Well, it is different because why.

You.

Can use it in writing a little bit differently. It depends on your application. But if you generalize enough, if you have edges from 0 RET to RET n and vertices, you can put edges around vertices, but you also can have free vertices.

Can you give an example of an application area where that's a useful distinction?

Well, I don't have to come up with it. I just can compare it to graphs and there's no reason to exclude it for the hypergraphs if graphs can.

No, but I think one of the things that's nice about hypergraphs is that sort of everything is wrapped together. It's just a hyper edge.

Yes. So if I can jump in. We have had a few philosophical discussions about this and it's something that we're actively thinking. So actually I agree that we, I mean, a one edge vertex are somehow conceptually similar. So actually my view and what is behind the philosophy of how we've designed this packlet so far is that vertices are somehow, you know, some, some kind of substrate where your hypergraphs are going to leave and the hypergraph data is actually edge data. So unary edge binary, et cetera. Right. So the principle here is that, as Jonathan says, we should be treating one edges effectively as vertex information. So that's why we're treating independent sort of free vertices as uninteresting, or we're sort of dismissing that case explicitly unless they carry edge information.

Right.

That's kind of the idea.

My opinion on this would be simply that a graph is a special case of a hypergraph where the hyper edges are of arity at most 2. And so that encompasses. That means you encompass the distinction between the vertex set and the edge set as a special case.

So one example in which this is relevant, there are two examples in which this might get relevant. One is multi edges, where you want to keep track of multiplicities. And the other is where you're doing something like categorical diagrams, rewriting, and then your objects or one morphisms are somehow, you know, distinguishable or not Distinguishable that those are the kind of contexts where you might care about this.

Wait a second. I thought. Okay, wait a minute. In, in the generalization of category theory. Well, okay, somebody who knows much more about this, like Jonathan probably does. I mean, I bet category theory generalizes. So it isn't just objects and morphisms 0 and 1.

Well, yes, there are many possible generalizations, but one of the most notable features of category theory is that you don't need to have a distinguished object set. Right. Because every object has an associated identity morphism. If you just know the HOM set, if you just know the set of class of morphisms, you can reconstruct the class of objects. And I think that that's really the question here. Right. So with a graph currently, if you just know the edge set, it is not possible to reconstruct the vertex set. Now, in my opinion, it's not clear. That has to be a fundamental design feature. It's, as I say, it's possible that you could treat freestanding vertices as hyper edges with just a single vertex in them. And that would extend to the hypergraph case beautifully. And that would be more like the category theory case again, the idea being you can always reconstruct the objects from the whole set.

Yeah, so I completely agree with that, Jonathan. I think what's happening here is more that the implementation that we're doing right now treats vertices as this substrate somehow. And then if we were, if we were to do things that involve sort of single vertex rules, then we would put a one edge on them to make the, to make it explicit.

Right.

So at the moment, for example, I showed some examples in a bit where we live a naked vertex floating to specifically to somehow represent that we are rewriting away, but we're keeping the context information in this sort of double push out rewriting sort of language for those familiar with it.

Yeah, I. My intuition is that this is not a necessary distinction, but we shall see.

Well, for pragmatic perspective, it's still useful, right? It's like in this example, this free vertex can match against three vertices that are part of an edge if you represent it as a unary edge. Instead you have to wrap your hypergraph it also, it's not very useful.

You have to decorate it with little edges.

Yeah, it's like. It may be as general as it is, but if you just want. Hold on, then as generally writing as possible. Why not?

Well, I mean, the reason we're seeing this issue is because we only have the notion of edges. We don't have the notion now, edges are just, you know, lists of vertices. We could also have a much more deeply nested structure to represent each edge, and then we wouldn't have the same. Quite the same story. So I'm saying, I mean, we're making a. Right now our edge is a bucket of vertices, but it could also be a nested tree of vertices and so on. Just, you know, it could have structure in the very structure of the edge.

Yeah, that's the point of the symmetry types, the symmetry tags that we have, that the edges themselves will carry some kind of structure.

I know that they could have an any structure. The edge in general could be an expression of any kind.

Yes.

That's not what we're doing here.

I mean, what you've just invented there is expression trees, Right. If you allow a hypergraph with arbitrary nesting, you get an expression tree.

Yeah, yeah, but which, and there's a, you know that the thing. Who was looking at that? UTI was looking at that, looking at kind of compiling everything to hypergraphs. Right.

Well, I, I was doing that and UCHI was working with some specific machines like finance.

Oh, that's right. Yeah, yeah, yeah. Okay, so what did you conclude from that, Nick? From the compiler?

Expression trees. Sure. Expression trees. You can do rewriting arbitrary expression trees to hypergraphs. And because we're doing in the Wolfram language, because we're doing rewriting with the expression trees you can form, you can turn any rewriting rule on those to hypergraph rewriting.

Okay. Maybe you're going to show.

And that's how my multi computational paclet worked, by turning usual rewriting rules to hypergraph rules.

Right. Except it's not actually in past tense, it's actually in the future tense because it's a packlet that I know you worked on and I think needs more, you know, needs to. Yeah, needs a future. Yeah. Okay, fine. All right, let's keep going here. So I think, I think I more or less understand this.

Yeah. That's the kind of motivation for free vertices. You're writing a bit more when you can swap them around. Okay, well, a bit more examples. There's like a highlight rule.

Yeah.

Highlight rule function that is in the packet that also shows what happened during the writing in a more explicit way, similar how we had in the set replace function model. So what age was matched in what was created there, you can annotated with some red dashed things around.

Yeah, well, it's not as exciting in this case because everything got red. But if we had a more complicated hypergraph There.

Yeah. Like here. Because it can match either against this edge or this edge. Right. It's either this one turns red or this one turns red.

Yeah.

Okay, hang on. Sorry. I'm sorry to take the discussion back one step, but on the, on the freestanding, on the free floating vertex rewriting thing. Yeah, Okay. I think the thing I'm objecting to there is that it seems like if you're going to go for that generalization, then that is insufficiently general because it seems to me that if, that, if you, if you want it to be the case, that you can specify, you know, I can rewrite this freestanding vertex to say, this edge or this hyper edge, and then that acts within an existing hyper edge. So like, that vertex acts on vertex 1 in that hyper edge on the green hyper edge on the right. Then shouldn't you also be able to define a rule that says. That specifies, that partially specifies a hyper edge. So for instance, it says, I've got a rule that's acting on ternary hyper edges, but what it does is it rewrites, say, vertex 1 and 2 to something else. If you see what I mean.

Sorry, sorry, sorry. Could you.

I'm not sure.

Okay, so right now what you've got is a rule that allows you to say, I can do rewriting of an individual vertex to something. Right? So if we take that ternary hyper edge there, the 1, 2, 3 hyper edge in light green.

This one.

Yeah. So then, for instance, that rule could match, say, vertex one and it could rewrite vertex one into something.

Right.

As it does there. Okay, but if we're going to allow that generalization, which I agree is a strict generalization of what we did in the physics project, then do we have an argument for not also allowing the generalization that says I can take vertices one and two in that hyper edge and rewrite those to something. So in other words, I can take any subset of a hyper edge and rewrite that to something. Why are we only allowing rewriting of single elements?

No, but we can do.

It's not a single element here, it's two elements. Right. What's the difference between. In this case?

That's a good question. Hang on, let me, let me figure this out. Well, I guess, I mean, ultimately it depends on the symmetry, right? You know. Okay, so suppose you, Suppose you had a. Suppose you had a 1, 2, 3 hyper edge with a cyclic symmetry. Then you could imagine wanting to say, you know, I want to rewrite the pair 1, 2, but not the pair 2, 1 or something.

Yeah, we Keep track of that with the same.

You can do it with labels.

Yeah, with the labels. We keep track of that because like.

Free vertices, they don't have any symmetry by itself because it's not an edge. Right. They can match like in any subset of vertices on the right hand side anywhere.

Right, right. Okay, so you're right that they don't have symmetries. But you know, for instance, could. What if I wanted to say, specify a binary edge, you know, 1, 2. And I want, and I want that to rewrite vertices 1, 2 in that ternary edge in that ternary hyper edge. Are you saying I would do that using labels?

No, but.

No, and you would have to include. Well, you have to match in the input.

Right.

If you want, like. Yeah, you, you have to do something like what? Draw some stuff.

Yeah, that's, that's great.

So you have, you have an edge, right. You want to match against a ternary one.

Right, exactly.

You have to make an additional edge. Otherwise if it's a binary edge, it's never going to match a ternary one, a part of a ternary one.

But then why do we allow a single vertex to match a ternary edge?

Right?

Because it's not an edge. It's like a, it's an exception that we do for free vertices. That's it. But why only for free.

But I'm saying if you're going to allow that generalization, then surely you need to go all the way.

You should allow any subset, any subset to match any subset.

Wait.

Yes. I think it's kind of different, Nick. I think that what Jonathan is asking here, if you were to match that to a ternary edge, I would simply include the ternary edge in the input.

Right.

So that's part of the parent matching. So you have to find the ternary edge and the binary edge and then you rewrite whatever you want and it's going to find the subsets, as you say.

Right.

But you have to specify the context of the ternary edge that is going to be preserved in the rewriting.

But what Jonathan. Well, I don't know. I think what Jonathan asks is for if I have a left hand side that just consists of a binary edge like this one, Jonathan says that should generalize to matching against part of the turnar edge.

Exactly right.

You're allowing for rewriting for your rewrites to match individual elements of a hyper edge as well as the whole hyper edge.

But I think. I see, I see, I see, I see that. I see the question here. I think the Change in perspective here is that we are not considering. Like as you pointed out earlier, we can have arbitrary structures as edges, basically. So the structures of inside the edge we can really look into inside the edge. It's like you have to. We're taking this perspective. We're not really looking into the edge unless it's necessary for some computation or some procedure. And the edges are taken as a whole with their, with their order and their symmetry tag.

Right.

And so if you want to specify a part of it, then you have to do some algorithm and then define new edges and then use those edges to do whatever procedure you want. But in, at the rewrite level, we are only dealing with the hyper edges as primitive elements in the hypergraph object.

Right, I'm totally with you on that. And that would be the, that's the WPP approach. But then that's. I would argue that's logically mutually exclusive with allowing rewriting on individual vertices, isn't it? If you're saying the hyper edges are the first class citizens, then you can't drill down and extract individual vertices to do rewriting on them.

Well, I mean, the thing here is that we are doing rewriting over hypergraph objects and the object carries vertices and edges as separate entities.

Right.

I mean, it's mostly the implementation is not so much the mathematical.

I don't think, I'm not convinced. But let's keep going because we don't need to get hung up on this particular issue. Yeah.

I just want to add one intuition that I have so that the rewriting should be intuitive in some way. If I see the binary edge on my left hand side and there is no binary edges on my target hypergraph, it shouldn't match.

It shouldn't match.

But when I see an input free vertex on the left hand side and a bunch of vertices, they kind of match.

Right. Just visually, it's a question point of view.

Right, I agree. Yeah, I agree. I agree. It's just a matter of where they are one edges.

Let's keep going because I think it will all become a bit clearer when we see what all the various operations are.

Yeah. So here now some examples with labels. Because the way we have labels on vertices also have some semantic meaning when you do the rewriting.

Okay.

So by default if this example, if this hyper edge is not. Doesn't have any labels on it.

Right.

It applies in all possible ways on this one.

I thought it's just a display thing, it's not really changing.

Well, photography is. But here you actually have some meaning. Especially when it's on the left hand side of your rule.

Wait, wait, wait, wait, wait. Vertex labels. A display func piece of functionality means something for the graph. That's weird.

It means something when you use them in your rules. Okay. And how it is used maybe gonna be explained in a minute.

Yeah, we might need to. I'm actually, I'm also of the opinion that putting it in the labels was a little bit, you know, unstable, in my opinion. But I mean, this is, I think for the sake of demonstration of the purpose, I think it's interesting. And then maybe we have to put it in another part of the object. I think Nick agrees.

Right.

Maybe you can look at it as an experimental feature.

Okay.

Yeah, yeah, yeah.

Labels in the rules.

Yeah.

Just to make sure that I understand what's going on here, if we make the analogy to expression rewriting, can I think of this as being the definition of constants as opposed to sort of quantified variables?

Yeah, basically it's not actually. It's more. It depends what you use as a labels. You can actually also use patterns and labels. Then they're going to be used as disjoint variables. So we have this special rule that if you have variables and labels, we just gather them all together and say, okay, all the labels should be this. All the patterns, all the variables and labels should be distinct.

Yeah. Except if two. Okay. What you're saying is, which is a horrible situation, but one that we have seen before, we saw in the Math Mathematics Project. Two X's are the same, but two X blanks are different. Is that correct? Yes.

In a way, labels would help us to mitigate this issue.

Exactly.

Yeah.

Because we are imposing this additional condition that when we actually have X and Y labels.

Right. As opposed to just using it from the vertex names with the convention that a literal vertex name is, is. I mean, somehow there's a sort of indistinguishable particle. I don't know what is the. What is the analogy? Is there a physics analogy? Two X's are just the same X, but two X blanks are distinct X blanks.

I think in this context all that's going on is that we, as I said, the vertices themselves are just some kind of background and you're putting your information, your labels on top is really what tells you what the data should be. And again, I agree that this is conceptually indistinguishable from doing one edges. And it might well be that we want to go super homogeneous and just do one edges, but that's kind of the idea that, you know, you want to express X&X2 copies of the same thing to either identical electrons, but they're in sort of two different points of space so they want, they want to live on different vertices. So at the level of the encoding in the language they actually have to live on one and two as you know, in a structure.

Let's keep going. I want to see what happens.

Wouldn't a more natural way to do that be to just have a multiplicity to say we want to match X and X but we could. But you know, but with strict multiplicity too or something.

I mean that can be. That can be an application. But I feel that it's more general, especially when you're doing pattern matching as we are, to keep things as separate as possible. And if you want to do multiplicity, you can always do it after the fact.

Right, okay, let's keep going.

Well, maybe a few of these examples because I think. Or we can just go.

I might show some of the, some of the symbolic examples because all I did was basically do an application of the hypergraphy write backlet which is to do sort of compositional algebra like categories and things like that. And it was one of the projects that we were doing at the institute to try and formalize several symbolic algebraic systems and purely in terms of rewriting. And now we, we have the sort of demonstration that it already works.

It's.

I mean it has many things to tweak and to improve, but it's working. So if you want to.

Let me just understand what this is. This is a multi way system of some kind. What is it?

Yeah, that's. We just apply the rewriting that we just tried to describe on this specific hypergraph which is a semi heap. Covers has a much more example.

I can, I mean that. That's going to be part of my. Maybe I can, I can go a bit more incremental and it will be clear what we're doing.

Now let's just show this one because it has some maybe styles different from yours.

Right.

So here is just a. It shows a bunch of things so that there's a pattern so that the labeled ages are also being propagated so that the actual labels are in data. I think I have some leakage symbols again.

There.

Where is it? Oh, that's right. It shouldn't be there.

I can show mine if you want. I have in my screen.

Yeah. Anyway, so it's just a multi way system of rewriting as usual.

Is there a merging?

Well, we can do contraction.

Yeah, but that has to take care of labels and some criteria.

Which means that you have right now, in what you drew so far, you do not have hypergraph isomorphism, hypergraph canonicalization. It's just.

Well, I do have.

There is. But they are technically different because they are differently labeled.

You can do kind of different things with this.

Right, I see.

You can turn them into some canonical graph and just edges maybe.

Yes.

These things are always amorphic, so they get contracted and so on. And this one is a morphic.

Exactly.

Okay.

That's how we do it. So we have.

Very cool. So. So should we see Carlos's stuff?

Yeah, let me show you. I'll just. I'll just brush a few examples which are of the same kind. So let me share screen one. Can everyone see that?

Yep. Okay. So I mean, this is not a dark mode person.

Yeah, I like it as a blackboard, sort of computational blackboard feeling. So. So, yeah, so basically traditional category composition, so two morphisms, FG composed to F compose G. And so if you want to, for example, check associativity, this I think is one of the main applications of this packlet that I had the intention to develop is to see algebraic axioms as emergent from rewrite property from rewrite properties of the system. And so in this case, you take this initial state and you apply the rewrite rule and sure enough, you get this multi way. I mean, these two final states are actually isomorphic, but the labels are different and that's what has the algebraic information. So you have the associativity axiom there.

Hold on, hold on, hold on, hold on, slow down. I'm not fast enough for this. Could you go back up to the top?

Yes.

Okay, so. So let's do commutativity first. You had the first picture which was commutativity, is that right?

No, no, this first picture, this is. This is simply defining an operation.

Right?

So this is defining what it means to compose two morphisms, two arrows, right?

FG ABC to make a composed morphism there.

Exactly. So this is one example, by the way, in which you use this dangling vertices without edges as sort of contextual information that is relevant for the system. So okay, yes. So then you choose your initial state carefully and you could choose a longer chain if you want, but this is sort of the minimal case that shows some behavior, some algebraic behavior. And then you have abcd and so three morphisms in a chain, right. And you basically just apply the rule, the composition rule to this. So you can apply either to fg, so you get FG on the, on the right or to hg, so you get GH on the left. And then you apply again because again it's, it's the same pattern and you get a single arrow from A to D, but one is labeled by F bracket GH and the other is right. So, so that, so the idea that this is at the level of hypergraphs unlabeled is confluent has some algebraic meaning. That's the entire sort of takeaway of the story, which is the cool feature that I would like to, you know, create for the mathematical community is like trying to replace action. This is going back to the sub axiomatic or pre axiomatics of approach where you replace enforcing axioms or listing them or enumerating them with simply spotting some rewriting behavior of the. If you, if your system is clever enough in this case, it keeps track of labels and all this kind of business that we've been, we've been showing.

Okay, so hold on, hold on, hold.

On, hold on, hold on.

So now algebraic equivalence becomes. Basically you say that those two graphs are equivalent, although they're labels, their sort of algebraic labels are different. And therefore you conclude there is an algebraic equivalence that you deduce from the equivalence of the graphs.

Correct? Basically that's the idea. So you can state it in very, very precise terms by saying that you started with a simple hypergraph, right? This meaning there's no multiple. And then you, you, if you just look at the hypergraph level without the labels, you ended up with a multi hypergraph because that's actually confluent. But it has, you know, if you're doing additive rewritings, you have two edges between A and B. So that way that multiplicity allows you to spot. So the condition is like, okay, there might be a non trivial state algebraic statement here. And I say non trivial because there are times where there's an algebraic statement but where it's rather trivial. And that doesn't give you some interesting axiom like associativity. We find some axioms. So let me just, if this idea is clear, I'll show several examples because they are basically the same, right? So the next is identity, identity arrows, right? And this is again using the single element. Again, could be a one edge, could be a vertex, doesn't matter too much. So what it does is, you know, takes a vertex and creates a duplicate of the vertex and then the identity arrow. So sure enough, you take some example, you, you have this and, you know, Y and X, and it creates X X here on the, on the right, and it creates Y Y here on the left. So this is just an example.

Now.

Another. So I want to show the interaction of two okay? So this is going to show the interaction of two such rules. So in this case, in this case, the dagger is just flipping the, the orientation of, of the morphism, right? So if you take just a normal V pattern, so fg, right? Abc, then you can apply both.