[
https://issues.apache.org/jira/browse/TINKERPOP3-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961964#comment-14961964
]
Marko A. Rodriguez commented on TINKERPOP3-863:
-----------------------------------------------
So, I have completed a proof of using Gremlin in optical computations. The
resultant Gremlin traversals all have this sequence strategically placed:
{code}
barrier().sideEffect{it.setBulk(1)})
{code}
Without, {{sack}} values grow with respects to bulk and don't serve as "energy"
obeying conservation.
The simplest solution we have thus far to to this problem which can easily be
extended (with backwards compatibility -- though perhaps a method Deprecation)
is {{withBulk(boolean)}}, where {{withBulk(true)}} is the default behavior.
This will only interfere with performance via a single boolean check on ever
{{Traverser.merge()}} where:
{code}
if(this.withBulk)
this.bulk = this.bulk + other.bulk;
else
this.bulk = 1
{code}
With the added {{GraphTraversalSource}} method, we can be confident that energy
flow algorithms don't require an in-depth knowledge on the users part to of
where barriers, bulking, etc. are happening in Gremlin steps.
> [Proposal] Turn off bulking -- or is there something more general? (hope not).
> ------------------------------------------------------------------------------
>
> Key: TINKERPOP3-863
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-863
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.1.0-incubating
> Reporter: Marko A. Rodriguez
> Assignee: Marko A. Rodriguez
> Fix For: 3.1.0-incubating
>
>
> I have a general question -- sometimes you want bulking and sometimes you
> don't. Why would you no want bulking? Well, lets say you have sack being 1.0
> and you want to represent energy diffusion and thus, if a traverser splits
> and goes to two adjacent neighbors, then each sack will be 0.5. Now, lets say
> those two traverser merge on the next step (a diamond shaped graph), the
> merged traverser's sack is 1.0 (excellent!). However, its bulk is 2.
> Dah............. Then the total energy in the graph is 2.0.
> Should we simply have "bulk" and "no bulk" or do we come up with a "bulk
> merge" model where users can ONLY add bulks (current default and the only
> method), multiple bulks, min/max bulks, etc. etc…………………….. Scared that the
> generalization might be an overkill.
> The difference is:
> {code}
> g.withBulk(false)….. // binary -- don't use bulking.
> g.withBulk(true)... // default behavior that is currently just sum the bulks
> together.
> // or do we go with
> g.withBulk(mult)….. // when two traversers merge, multiply their bulks.. why
> would you do that, I have no idea, but its general.
> g.withBulk(one) … // would be like binary=false .. always merge to 1 and
> thus, one BinaryOpeartor(x,y) -> 1
> {code}
> Is this generalization of the bulk merge operator useful? Or do we say -- if
> you want to do complex functions on "energy" (bulk), you do it via
> sack........................
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
