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

Reply via email to