[
https://issues.apache.org/jira/browse/TINKERPOP3-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko A. Rodriguez closed TINKERPOP3-776.
-----------------------------------------
Resolution: Won't Fix
Going to close this "grab bag." There are various specific technical tickets
that are open (or closed) that deal with making "traverser as particle" a
reality -- new {{GroupStep}}, new {{sack()}} work, new merge sack work, etc.
In January, at GraphDay, I will be presenting on some new work demonstrating
the similarity between Gremlin and quantum mechanics. In fact, its eerily
similar assuming you use traverser "phases." That will close the loop on the
ideas discussed here.
> Grab bag of ideas around "traverser as particle."
> -------------------------------------------------
>
> Key: TINKERPOP3-776
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-776
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.0.1-incubating
> Reporter: Marko A. Rodriguez
> Assignee: Marko A. Rodriguez
>
> *Background*
> A traverser is a discrete particle that moves over a graph. Every time a
> traverser moves, it makes a clone of itself in a processed called "splitting"
> ({{Traverser.split()}}). Each split traverser is identical to its parent in
> that there is no "loss of data" (e.g. bulk, sack) when a split occurs. Why
> "split"? When a traverser comes to a fork in the graph (e.g.
> {{out('knows')}}), it can either take one branch (no splitting required --
> "random walker") or it can take all branches (splitting required --
> "diffusing walker"). Gremlin was designed such that it takes all paths and
> thus, the traverser splits. The primary rationale for this fundamental design
> choice is that its more efficient to branch than choose as once data is
> touched, use it!
> *Applications*
> Are there aspects of particle physics/computing that we can steal which will
> allow us to do novel computations with Gremlin?
> 1. The idea of particle's splitting with the same bulk and merging with
> {{bulkA+bulkB}} allowed us to leverage Pascal's Triangle
> (https://en.wikipedia.org/wiki/Pascal%27s_triangle) for efficiently computing
> the number of paths to any particular vertex in a (multi-)rooted spanning
> tree (i.e. traversal). [*DONE*]
> 2. In physics there are particles and anti-particles. Annihilation occurs
> when an anti-particle interacts with a particle. If traverser bulks can take
> on negative values then when two traversers touch and their bulks' are
> summed, either constructive (they have the same sign {{++/--}}) or
> destructive (they have different signs {{+-/-+}}) interference occurs. If the
> sum equal 0, then the merged traverser dies (annihilation). Imagine emanating
> "positive" traversers from vertex A and "negative" traversers from vertex B.
> A {{repeat(out().groupCount('x'))}} would yield the "fuzzy difference"
> {{subgraph(A) - subgraph(B)}}. In essence, "give me everything related to A,
> that is not related to B." This is related to spreading activation potentials
> with inhibitory control in biological neural networks
> (http://www.scholarpedia.org/article/Neural_inhibition), where the entire
> local region around B can be pulled out of the traversal computation
> (analogous to "blinding" the traversal from touching particular areas of the
> graph). An interesting follow on would be to provide a way to do "lateral
> inhibition" (https://en.wikipedia.org/wiki/Lateral_inhibition). Lets say
> there is a "fork in the road." A split would yield the same traverser down
> each fork. However, you could yield "positive traversers" down some branches
> and "negative traversers" down others in order to accentuate those traversal
> paths (subgraphs) that have a strong signal and downplay those paths
> (subgraphs) that have a weak signal. In application: "Give me everything
> {{out('friend')}} related to A, but inhibit everything {{out('family')}}
> along the way." This would yield a friendship subgraph where no vertices have
> family members in the graph (i.e. the friendship graph intersected with the
> complement of the family graph).
> 3. ...to be continued.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
