Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specifying the essential identity of a match morphism #21

Open
kris-brown opened this issue May 16, 2024 · 0 comments
Open

Specifying the essential identity of a match morphism #21

kris-brown opened this issue May 16, 2024 · 0 comments

Comments

@kris-brown
Copy link
Collaborator

kris-brown commented May 16, 2024

A match morphism triggers an event to happen in the future. There is some ambiguity about what it means for that match to be "still existing" when that time comes around and it's time to fire the event. The current logic is very strict about this: there needs to exist a morphism $L\xrightarrow{m_{now}} X_{now}$ that is equal to the composite $L\xrightarrow{m_{past}}X_{past}\overset{update}{\nrightarrow} X_{now}$. This means that a rewrite rule, which merges two parallel edges and adds their weights together, will fail to fire if the target vertex is deleted and recreated in the intervening time. This may or may not be what you want; it depends on whether you consider the target of the edge to be constitutive of its identity.

Another example involves a door with a boolean attribute saying whether or not it's closed. Someone may be triggered to go through the door soon if the door is open, and if the door closes but reopens in the intervening time, we may wish that to be equivalent to the door having stayed open the whole time, rather than the clock deactivating when it closes and then being resampled when it reopens.

The right data for this is a subobject $L_{fix}\xhookrightarrow{fix} L$. However, CSet subobjects do not give us fine enough granularity to say "include the edge, but not its tgt vertex", thus we want a subobject in C-Par. Now the condition for the match still being valid is $fix;m_{now} = fix;m_{past};update$.

The current behavior would be that $L_{fix}$ is all of $L$'s combinatorial data, but none of its attribute data. This seems arbitrary. What is a sensible default for $L_{fix}$? I think when $L$ is specified via @acset_colim, the representables that are explicitly mentioned are great candidates for what belongs to $L_{fix}$.

Note: this change can only be made within AlgebraicRewriting.Incremental

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant