[
https://issues.apache.org/jira/browse/TINKERPOP3-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963490#comment-14963490
]
Marko A. Rodriguez edited comment on TINKERPOP3-863 at 10/19/15 3:46 PM:
-------------------------------------------------------------------------
With the ability to turn off bulking (which will be necessary for almost any
type of "energy flow" algorithm using sacks), check out how simple the
following query become.
BEFORE {{TraverserRequirement.ONE_BULK}}:
{code}
g.withSack([1.0,0.0],sackSum).V(middle).repeat(
union(out('right').sack{a,b -> [coin * (a[0] + a[1]),0]},
out('left').sack{a,b -> [0,coin * (a[0] -
a[1])]}).barrier().sideEffect{it.setBulk(1)}).times(loops).
group().by(id).by(sack().fold([0,0],sackSum)).order(local).by(keyDecr).next()
{code}
AFTER {{TraverserRequirement.ONE_BULK}}:
{code}
g.withBulk(false).withSack([1.0,0.0],sackSum).V(middle).repeat(
sack{a,b -> [coin * (a[0] + a[1]),coin * (a[0] - a[1])]}.
union(out('right').sack{a,b -> [a[0],0]},
out('left').sack{a,b -> [0,a[1]]}).barrier()).times(50).
group().by(id).by(sack().fold([0,0],sackSum)).order(local).by(keyDecr)
{code}
This is what was removed:
{code}
.barrier().sideEffect{it.setBulk(1)}
{code}
...realize that there is a more complex algorithm I'm running where the energy
can run forward and backward in time. The ability to get the
{{barrier().sideEffect(it.setBulk(1))}} locations right was a nightmare and I
know how Gremlin works under the hood. So, in short, this is a blessing.
was (Author: okram):
With the ability to turn off bulking (which will be necessary for almost any
type of "energy flow" algorithm using sacks), check out how simple the
following query become.
BEFORE {{TraverserRequirement.ONE_BULK}}:
{code}
g.withSack([1.0,0.0],sackSum).V(middle).repeat(
union(out('right').sack{a,b -> [coin * (a[0] + a[1]),0]},
out('left').sack{a,b -> [0,coin * (a[0] -
a[1])]}).barrier().sideEffect{it.setBulk(1)}).times(loops).
group().by(id).by(sack().fold([0,0],sackSum)).order(local).by(keyDecr).next()
{code}
AFTER {{TraverserRequirement.ONE_BULK}}:
{code}
g.withBulk(false).withSack([1.0,0.0],sackSum).V(middle).repeat(
sack{a,b -> [coin * (a[0] + a[1]),coin * (a[0] - a[1])]}.
union(out('right').sack{a,b -> [a[0],0]},
out('left').sack{a,b -> [0,a[1]]}).barrier()).times(50).
group().by(id).by(sack().fold([0,0],sackSum)).order(local).by(keyDecr)
{code}
This is what was removed:
{code}
.barrier().sideEffect{it.setBulk(1)}
{code}
...realize that there is a more complex algorithm I'm running where the energy
can run forward and backward in time. The ability to get the
{{barrier().sideEffect{it.setBulk(1)}}} locations right was a nightmare and I
know how Gremlin works under the hood. So, in short, this is a blessing.
> [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)
