Comments (3)
@ggazzi about your first comment:
"an application condition is essentially a constraint whose "antecedent-object" is the left-hand side of the rule"
I don't think that applies, as only atomic constraints have premise objects and only the negative ones could be used to emulate NACs like that. Furthermore, the module Constraints
deals not only with atomic, but with the more generic (logical) form of constraints.
Moreover, there is no notion (as far as I know) of shifting constraints over morphisms, as they apply over the objects of a category, not the morphisms themselves1.
Instead, this shifiting of nacs over morphisms does belong to the class of NAC-adhesive HLR Categories, as shown in Lambers2010, section 3.3. This also seems to be the case for all the other NAC operations implemented so far.
I agree with the change of MatchRestriction
ot MorphismType
. And I also think that there is no problem in not knowing right now which are (all) kinds of morphisms we may have to deal with. Worst case: we make the adhesive type class requiring concrete categories to provide which are the M-, E- or any other necessary class of morphisms.
1 Maybe this could be case with nested application conditions?
from verigraph.
Regarding nacDownwardShift
, couldn't we frame it as shifting a constraint rather than an application condition? After all, an application condition is essentially a constraint whose "antecedent-object" is the left-hand side of the rule.
In this case, we could rename it to shiftConstraintDown
, place it on the constraint module, and document it as: "Given a constraint c : P -> C
and a morphism f : P -> P'
, obtains an equivalent set of constraints c'i : P' -> C
. That is, for any graph, the original constraint c
is satisfied if and only if all constraints c'i
are satisfied."
from verigraph.
Regarding the match restriction and NAC satisfaction, this will interact with a complexity of symbolic graphs: we don't want to restrict matches to be completely monic, just monic on the graph part (the attribute part may be non-monic). So we'll need to express different classes of morphisms, which may be specific to particular categories. This is all to say that we don't have enough information to make a good choice at this point.
In this case, I think match restriction and NAC satisfaction belong in the DPO module, along with its configuration (MorphismsConfig
). We could even remove MatchRestriction
, use just a MorphismType
.
Even the NAC satisfaction could be removed. We could have a function findSpanCommuter : MorphismType -> MorphismType -> morph -> morph -> morph
, where the first restriction is for the mappings induced by the span and the second restriction is for the mappings outside the image of the span. Then, NacSatisfaction
could also be replaced by a simple MorphismType
.
from verigraph.
Related Issues (20)
- Fix "FIXME" issue in src/library/SndOrder/Morphism/EpiPairs.hs
- Fix "TODO" issue in src/library/TypedGraph/DPO/GraphProcess.hs
- Fix "TODO" issue in src/library/TypedGraph/DPO/GraphProcess.hs HOT 1
- Fix "TODO" issue in src/library/TypedGraph/Partitions/GraphPartition.hs HOT 1
- Fix "TODO" issue in src/library/TypedGraph/Partitions/GraphPartition.hs HOT 1
- Fix "TODO" issue in src/library/XML/ParseSndOrderRule.hs
- Fix "TODO" issue in src/library/Util/List.hs
- Fix "FIXME" issue in src/library/Abstract/Category/AdhesiveHLR.hs
- Type class for isomorphism checks HOT 2
- Terrible performance of isomorphism check between morphisms
- Fix "TODO" issue in src/library/Analysis/EssentialCriticalPairs.hs
- Final Pullback Complement Place
- Scheduling rule executions HOT 1
- Representation of Doubly-Typed Graphs
- Duplicated code for conflicts and dependencies HOT 1
- Unclear types for conflicts and dependencies
- Duplicated types NamedX
- Output for overlappings
- Fix "TODO" issue in src/library/Abstract/Rewriting/DPO.hs
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from verigraph.