[jira] [Updated] (TINKERPOP3-863) [Proposal] Turn off bulking -- or is there something more general? (hope not).

["Marko A. Rodriguez (JIRA)" <ji...@apache.org>]

     [ 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)