[
https://issues.apache.org/jira/browse/TINKERPOP3-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko A. Rodriguez updated TINKERPOP3-863:
------------------------------------------
Description:
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........................
was:
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:
{cpde}
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........................
> [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: New Feature
> 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)
