[
https://issues.apache.org/jira/browse/TINKERPOP3-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14941614#comment-14941614
]
Matt Frantz commented on TINKERPOP3-863:
----------------------------------------
It was wrong of me to raise the issue of {{sack}} boundaries. This refers to
the desire to use {{withSack}} on a child traversal, so that the sack
definition is not global to the entire traversal, as discussed in
TINKERPOP3-716. But let's set that aside for now.
It seems like the split/merge operations work correctly up until the final
iteration through a bulked traverser. Perhaps that should be considered a
"split" operation. The traverser is bulked until it is iterated, at which
point it splits into the individual non-bulk traversers. That would allow the
split operator to be applied again.
> [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)
