You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of DPO with attributes allows the apex $I$ of a rule to have a variable which is bound to a variable in $L$ (this is required in order for $L \leftarrowtail I$ to be monic) and sent to either a variable or a concrete value in $R$. If sent to a concrete value, the rule has the effect of 'updating' the attribute to the fixed value. If sent to a variable in $R$, we could either specify no further information (in which case the value of the attribute is preserved) or give an "expression" as a function of the bound variables by the match, which again would 'update' the value of the attribute.
This is very convenient, because it avoids the tedium that we see when DPO forces one to delete something in order to change one of its outgoing homs (e.g. one must delete an edge to change its src). However, this convenience is not worth the complexity that it introduces, which has led to two practical problems:
The pushout complement square required to do this 'updating' is not truly a pushout square. This makes writing the pushout_complement function inherently buggy.
The bottom map $G \leftarrowtail K$ in the result of applying a rewrite rule is not truly monic. With recent updates to Catlab, the subobject code will now throw an error.
Removing this convenient 'feature' will simplify the library code, but it remains to be seen how hard it will be to reproduce our earlier examples without this convenience. For example, in a Lotka Volterra simulation, the counter on the vertices of the graph (representing grass growing) needs to update periodically. We cannot delete and recreate this vertex due to an unknown number of things depending on it. Because this attribute luckily happens to be an Int, we might get away with having another object DaysLeftToGrow with a hom into V and treat this combinatorially. Or the attribute could look more like a relation that we happen to enforce is a function (we have this same option when we really need the ability to change hom values via DPO).
The current implementation of DPO with attributes allows the apex$I$ of a rule to have a variable which is bound to a variable in $L$ (this is required in order for $L \leftarrowtail I$ to be monic) and sent to either a variable or a concrete value in $R$ . If sent to a concrete value, the rule has the effect of 'updating' the attribute to the fixed value. If sent to a variable in $R$ , we could either specify no further information (in which case the value of the attribute is preserved) or give an "expression" as a function of the bound variables by the match, which again would 'update' the value of the attribute.
This is very convenient, because it avoids the tedium that we see when DPO forces one to delete something in order to change one of its outgoing homs (e.g. one must delete an edge to change its src). However, this convenience is not worth the complexity that it introduces, which has led to two practical problems:
pushout_complement
function inherently buggy.Removing this convenient 'feature' will simplify the library code, but it remains to be seen how hard it will be to reproduce our earlier examples without this convenience. For example, in a Lotka Volterra simulation, the counter on the vertices of the graph (representing grass growing) needs to update periodically. We cannot delete and recreate this vertex due to an unknown number of things depending on it. Because this attribute luckily happens to be an
Int
, we might get away with having another objectDaysLeftToGrow
with a hom intoV
and treat this combinatorially. Or the attribute could look more like a relation that we happen to enforce is a function (we have this same option when we really need the ability to change hom values via DPO).A general solution may be patch graph rewriting.
The text was updated successfully, but these errors were encountered: