[
https://issues.apache.org/jira/browse/TINKERPOP3-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko A. Rodriguez updated TINKERPOP3-960:
------------------------------------------
Description:
Currently, {{Traverser.bulk()}} is a {{long}}. This should be generalized to
support any type of "bulk" that can be split, merged, and has a magnitude,
where our current representation would be a {{LongBulk}}.
There are three reasons to support this.
1. Right now we use {{Traverser.sack()}} to handle "energy flows" (0/0 to 1.0
energy in a traverser). We have introduced this ugly
{{TraversalSource.withBulk(false)}} to allow these to semantically make sense
(i.e. remain unitary). The "energy" should be the "bulk" as it can be split,
merged, and has a magnitude.
2. We can support complex numbers for bulks (and complex number arrays). There
is currently no strong use case for this beyond quantum simulation and wave
dynamics, but you never know what might unfold. A solid algorithm here would be
epic.
3. We need to be able to support {{BigInteger}} as the bulking model on complex
graphs easily blows {{long}}. There have been numerous times where I wanted to
{{repeat()}} more times, but can't without incurring long overflow and thus,
negative bulk. If the computation calls for it, a user should be able to use
{{BigInteger}}.
--------------------------
{code}
public interface Bulk<T> {
public boolean canMerge(Bulk<T> otherBulk);
public void merge(Bulk<T> otherBulk);
public Bulk<T> split();
public Number magnitude();
public T get();
public static Bulk<T> identity();
}
{code}
Our current model would be:
{code}
public class LongBulk extends Bulk<Long> {
public boolean canMerge(LongBulk otherBulk) { return true; }
public void merge(LongBulk otherBulk) { this.count += otherBulk.count; }
public LongBulk split() { return new LongBulk(this.count); }
public Number magnitude() { return this.count; }
public Long get() { return this.count; }
public static LongBulk identity() { return new LongBulk(1); }
}
{code}
Another benefit of this is that bulking is now decoupled from the {{Traverser}}
class and thus, you would be able to use different bulk classes with the same
{{Traverser}}-species:
{code}
g.withBulk(BigIntegerBulk.class).V().out().out()
{code}
...where the default is assumed {{LongBulk}} and thus, you don't have to
specify a {{withBulk}}. For backwards compatible sake, {{withBulk(false)}}
would simply be {{IdentityLongBulk}} would would just return a {{1}} for
everything.
We will want to then expose {{it.bulk()}} methods so algorithms can alter the
bulk as they see fit. However, this is where a backwards compatibility issue
would happen. {{Traverser.bulk() -> Bulk}} and {{Traverser.magnitude() ->
Number}} (sidenote ---- perhaps "magnitude" is just called "count").
{code}
g.withBulk(UnitaryBulk).V(0).bulk(1.0).outE().bulk(mult).by('weight').inV()
{code}
What is stellar about this is that it frees up "sack" for more "objects" and
not for "bulking" when long is not sufficient. Thus, we promote that "sack" is
for objects and "bulk" is for, well, bulk! Now we no longer have this weird
tension between bulk and sack as they have two different uses. Bulking is for
altering the "magnitude" of a traverser and sacking if for gathering
statistics/data about the graph along the way.
was:
Currently, {{Traverser.bulk()}} is a {{long}}. This should be generalized to
support any type of "bulk" that can be split, merged, and has a magnitude,
where our current representation would be a {{LongBulk}}.
There are three reasons to support this.
1. Right now we use {{Traverser.sack()}} to handle "energy flows" (0/0 to 1.0
energy in a traverser). We have introduced this ugly
{{TraversalSource.withBulk(false)}} to allow these to semantically make sense
(i.e. remain unitary). The "energy" should be the "bulk" as it can be split,
merged, and has a magnitude.
2. We can support complex numbers for bulks (and complex number arrays). There
is currently no strong use case for this beyond quantum simulation and wave
dynamics, but you never know what might unfold. A solid algorithm here would be
epic.
3. We need to be able to support {{BigInteger}} as the bulking model on complex
graphs easily blows {{long}}. There have been numerous times where I wanted to
{{repeat()}} more times, but can't without incurring long overflow and thus,
negative bulk. If the computation calls for it, a user should be able to use
{{BigInteger}}.
--------------------------
{code}
public interface Bulk<T> {
public boolean canMerge(Bulk<T> otherBulk);
public void merge(Bulk<T> otherBulk);
public Bulk<T> split();
public Number magnitude();
public T get();
public static Bulk<T> identity();
}
{code}
Our current model would be:
{code}
public class LongBulk extends Bulk<Long> {
public boolean canMerge(LongBulk otherBulk) { return true; }
public void merge(LongBulk otherBulk) { this.count += otherBulk.count; }
public LongBulk split() { return new LongBulk(this.count); }
public Number magnitude() { return this.count; }
public Long get() { return this.count; }
public static LongBulk identity() { return new LongBulk(1); }
}
{code}
Another benefit of this is that bulking is now decoupled from the {{Traverser}}
class and thus, you would be able to use different bulk classes with the same
{{Traverser}}-species:
{code}
g.withBulk(BigIntegerBulk.class).V().out().out()
{code}
...where the default is assumed {{LongBulk}} and thus, you don't have to
specify a {{withBulk}}. For backwards compatible sake, {{withBulk(false)}}
would simply be {{IdentityLongBulk}} would would just return a {{1}} for
everything.
We will want to then expose {{it.bulk()}} methods so algorithms can alter the
bulk as they see fit. However, this is where a backwards compatibility issue
would happen. {{Traverser.bulk() -> Bulk}} and {{Traverser.magnitude() ->
Number}} (sidenote ---- perhaps "magnitude" is just called "count").
{code}
g.withBulk(UnitaryBulk).V(0).bulk(1.0).outE().bulk(mult).by('weight').inV()
{code}
What is stellar about this is that it frees up ``sack" for more "objects" and
not for "bulking" when long is sufficient. Thus, we promote that "sack" is for
objects and "bulk" is for, well, bulk! Now we no longer have this weird tension
between bulk and sack as they have two different uses. Bulking is for altering
the "magnitude" of a traverser and sacking if for gathering statistics/data
about the graph along the way.
> Add a Bulk class which is used by Traverser
> -------------------------------------------
>
> Key: TINKERPOP3-960
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-960
> Project: TinkerPop 3
> Issue Type: Bug
> Components: process
> Affects Versions: 3.1.0-incubating
> Reporter: Marko A. Rodriguez
> Assignee: Marko A. Rodriguez
>
> Currently, {{Traverser.bulk()}} is a {{long}}. This should be generalized to
> support any type of "bulk" that can be split, merged, and has a magnitude,
> where our current representation would be a {{LongBulk}}.
> There are three reasons to support this.
> 1. Right now we use {{Traverser.sack()}} to handle "energy flows" (0/0 to 1.0
> energy in a traverser). We have introduced this ugly
> {{TraversalSource.withBulk(false)}} to allow these to semantically make sense
> (i.e. remain unitary). The "energy" should be the "bulk" as it can be split,
> merged, and has a magnitude.
> 2. We can support complex numbers for bulks (and complex number arrays).
> There is currently no strong use case for this beyond quantum simulation and
> wave dynamics, but you never know what might unfold. A solid algorithm here
> would be epic.
> 3. We need to be able to support {{BigInteger}} as the bulking model on
> complex graphs easily blows {{long}}. There have been numerous times where I
> wanted to {{repeat()}} more times, but can't without incurring long overflow
> and thus, negative bulk. If the computation calls for it, a user should be
> able to use {{BigInteger}}.
> --------------------------
> {code}
> public interface Bulk<T> {
> public boolean canMerge(Bulk<T> otherBulk);
> public void merge(Bulk<T> otherBulk);
> public Bulk<T> split();
> public Number magnitude();
> public T get();
> public static Bulk<T> identity();
> }
> {code}
> Our current model would be:
> {code}
> public class LongBulk extends Bulk<Long> {
> public boolean canMerge(LongBulk otherBulk) { return true; }
> public void merge(LongBulk otherBulk) { this.count += otherBulk.count; }
> public LongBulk split() { return new LongBulk(this.count); }
> public Number magnitude() { return this.count; }
> public Long get() { return this.count; }
> public static LongBulk identity() { return new LongBulk(1); }
> }
> {code}
> Another benefit of this is that bulking is now decoupled from the
> {{Traverser}} class and thus, you would be able to use different bulk classes
> with the same {{Traverser}}-species:
> {code}
> g.withBulk(BigIntegerBulk.class).V().out().out()
> {code}
> ...where the default is assumed {{LongBulk}} and thus, you don't have to
> specify a {{withBulk}}. For backwards compatible sake, {{withBulk(false)}}
> would simply be {{IdentityLongBulk}} would would just return a {{1}} for
> everything.
> We will want to then expose {{it.bulk()}} methods so algorithms can alter the
> bulk as they see fit. However, this is where a backwards compatibility issue
> would happen. {{Traverser.bulk() -> Bulk}} and {{Traverser.magnitude() ->
> Number}} (sidenote ---- perhaps "magnitude" is just called "count").
> {code}
> g.withBulk(UnitaryBulk).V(0).bulk(1.0).outE().bulk(mult).by('weight').inV()
> {code}
> What is stellar about this is that it frees up "sack" for more "objects" and
> not for "bulking" when long is not sufficient. Thus, we promote that "sack"
> is for objects and "bulk" is for, well, bulk! Now we no longer have this
> weird tension between bulk and sack as they have two different uses. Bulking
> is for altering the "magnitude" of a traverser and sacking if for gathering
> statistics/data about the graph along the way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
