explorable-viz / fluid

Data-linked visualisations

Home Page:http://f.luid.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Fwd slicing to include sinks which aren’t inputs

rolyp opened this issue · comments

As part of #867, we arranged for every vertex allocated during graph evaluation to have a non-empty set of out neighbours. However, when we consider opposite graphs as well, it’s clear that we can have graphs whose sinks aren’t inputs, since they correspond (in the original graph) to a source which isn’t an output. That arises whenever we make an output that doesn’t get used. Also, requiring every node to have at least one dependent is (mathematically) equivalent to requiring that forward slicing preserves $\bot$, which is probably a strong requirement than we want. (Just as we can’t restrict backward slicing to preserve $\top$, because of laziness.)

Forward slicing needs to automatically include into the “starting slice” any sinks which aren’t in the input – these are “costless resources”, i.e. things that can be made without any input resources at all. However, I’m a bit unclear on whether this is a change to forward slicing itself or merely how we “use” it. (In particular there doesn’t seem to be an analogous implied change to backward slicing.)

  • Stack overflow in inEdges on convolution example (~7000 non-input sinks leads to concat of 10,000 lists)
  • Stack overflow in fromEdgeList (actually inMap, actually init)
  • Include sinks which aren’t inputs into fwd – 50 failures reduce to 6 comparing FwdDlBwdOp and FwdDlCmp

See also: