[
https://issues.apache.org/jira/browse/TINKERPOP3-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964408#comment-14964408
]
ASF GitHub Bot commented on TINKERPOP3-863:
-------------------------------------------
Github user okram commented on the pull request:
https://github.com/apache/incubator-tinkerpop/pull/112#issuecomment-149407781
Bulk and sack do not play well together when you are dealing with "energy
flows." Please see the existing 3.0.1-SNAPSHOT docs for a simple example:
```
gremlin>
g.withSack(1.0f,sum).V(1).local(outE('knows').barrier(normSack).inV()).in('knows').barrier().sack()
//(5)
==>1.0
==>1.0
gremlin>
g.withSack(1.0f,sum).V(1).local(outE('knows').barrier(normSack).inV()).in('knows').barrier().sideEffect{it.setBulk(1)}.sack()
//(6)
==>1.0
```
```
5. The barrier() merges the two traversers at vertex 1 into a single
traverser whose sack is 1.0.
6. There is now a single traverser with bulk of 2 and sack of 1.0 and thus,
setting the bulk to 1 yields the expected 1.0.
```
Now look at what changes I made to the docs and see how you no longer need
`sideEffect{it.setBulk(1)}`.
> [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)
