Dual of `fwd` fails because unused vertices aren’t in graph
rolyp opened this issue · comments
For the relationship between De Morgan dual, adjoints and opposite graph to hold, the graph must include all input vertices (e.g. from e
and γ
). Otherwise, for example, attempting to compute the dual of fwd
by complementing the selection and then running bwd
on the opposite graph will fail because the complement will include nodes which aren’t in the graph. Currently when we run fromFoldable
to construct the final graph, it will only include input vertices that appear as the target of an edge.
Note: graph slicing really needs to produce a reachable subgraph, i.e. only contain vertices that are reachable. After all the whole point of the slice is that we can use to to query a value to see which of its nodes are included in the slice. Would it be reasonable to have two kinds/modes of graph, one where the set of vertices is fixed up front (with the constraint that all vertices mentioned in the edge list are in that set), and one where the set of vertices contains only those mentioned in the edge list?
Alternatively, maybe we should think of the graph resulting from graph evaluation already as a kind of backward slice (for the whole output). Then we would need to ensure that the incoming selection for fwd
is a subset of the vertices in the graph. (Since nodes that aren’t used won’t appear in g
.)
-
fwdSliceDual
broken inasmuch as it tolerates non-emptyαs0 \\ sinks g0
– replace by(dual gc).bwd
- (Temporarily?) set benchmark tests to run all the time
TightenGraphImpl.fromFoldable
to prohibit duplicate entries?-
addIfMissing
precludes this – instead start by asserting that existing entry is necessarily empty - Push
NonEmptySet
invariant intoextend
method Take vertex set (known up-front) as argument, incl. vertices in ambientg
❌ incompatible with graph slicingRename tofromEdgeList
-
- With
(dual gc).bwd
vs.fwdSliceDual
, “existing entry necessarily empty” constraint above fails – investigate- Verify duplicate keys always provide same information
Understand how duplicate information arises❌ not feasible to debug, doesn’t matter for now given above
See also: