[jira] [Commented] (TINKERPOP3-776) Grab bag of ideas around "traverser as particle."

["Dylan Millikin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP3-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14644499#comment-14644499 ] 

Dylan Millikin commented on TINKERPOP3-776:
-------------------------------------------

I recently posted a question to gremlin-users along these lines. I would love to see something like this. There are a few hitches along the way though from what I understood of my conversation with stephen.

Now I might be going beyond the scope of this issue, but for the sake of keeping it in mind:

If you aren't interested in obtaining a result set from your traversals, and instead are looking at getting those traversal particles (or tokens) to mutate the graph as they go. Then your use case will most likely involve running multiple traversals (not just splits) at the same time (threaded).

This leads to a couple of issues:

- multiple threaded traversals aren't guarantied to see each other's mutations (or perhaps even just each other?) from what I gathered. Though this might depend on the vendor, but I'm going with tinkergraph at this point.
- if you consider a single unit of time to be a "cycle". Then you would want to be able to guaranty that each traversal walked the graph one element per cycle. (or maybe more depending on the element "weight")

Both of these work out of the box in a traversal split scenario (I think) but if you want a more elaborate neural scenario for example, it becomes a bit of a headache.

> 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
>            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)