[
https://issues.apache.org/jira/browse/TINKERPOP3-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko A. Rodriguez updated TINKERPOP3-571:
------------------------------------------
Description:
I want to be able to do this in OLAP:
{code}
__(12,21,3,4,75).is(gt,10).sum()
{code}
An idea is this... For any {{Iterator<Object>}}, we need to be able to generate
a Graph where:
{code}
g.addVertex(id,12)
g.addVertex(id,21)
g.addVertex(id,3)
g.addVertex(id,4)
g.addVertex(id,75)
{code}
...and then the start of the OLAP traversal has a "hidden prefix" of {{g.V.id}}
thus, behind the scenes, what is being executed is:
{code}
g.V.id.is(gt,10).sum()
{code}
If we can make OLAP object processing just as natural as graph processing, then
I don't see why Gremlin is not the craziest functional language to date:
* single machine or distributed
* supports non-terminal sideEffects (i.e. {{groupCount()}} is not the "end"
(sideEffect is key S-x->S))
* has natural branching constructs -- not just serial stream processing.
* supports an execution structure that is a graph, not a DAG (e.g.
{{repeat()}}, {{back()}}, ...)
* fundamentally an arbitrary execution graph with {{jump()}} (low-level,
but there)
* this provides turing completeness as we have a non-serial "program
counter" (the step ID is analogous to instruction's location in RAM and a
traverser can jump to any step ID it wants). Moreover we have two random access
memories ({{sack}} (local) and {{sideEffect}} (global)).
* can be easily expressed in any host language as its represented using a
fundamental concept in all programming languages -- fluent function chaining
(monoid state modulation)
* for JVM languages, simply {{import Traversal}} and use the syntax of the
importing language (e.g. Jython, Rhino, Groovy, Scala, Clojure, etc.)
* can be used as a database query language (and/)or an arbitrary data flow
language (given this proposal).
* has numerous execution engines
(Giraph,MapReduce,Spark,Fulgora,TinkerGraph,...) with different time/space
complexities.
* has remote execution functionality via GremlinServer (with monitoring).
* ...and, native support for the most complex data structure there is, the
graph (i.e. {{outE}}, {{in}}, etc.)
Its mind boggling actually... I can't think of anything else like this.
[~mbroecheler] @dkuppitz [~spmallette] @joshsh
was:
I want to be able to do this in OLAP:
{code:groovy}
__(12,21,3,4,75).is(gt,10).sum()
{code}
An idea is this... For any {{Iterator<Object>}}, we need to be able to generate
a Graph where:
{code:groovy}
g.addVertex(id,12)
g.addVertex(id,21)
g.addVertex(id,3)
g.addVertex(id,4)
g.addVertex(id,75)
{code}
...and then the start of the OLAP traversal has a "hidden prefix" of {{g.V.id}}
thus, behind the scenes, what is being executed is:
{code:groovy}
g.V.id.is(gt,10).sum()
{code}
If we can make OLAP object processing just as natural as graph processing, then
I don't see why Gremlin is not the craziest functional language to date:
* single machine or distributed
* supports non-terminal sideEffects (i.e. {{groupCount()}} is not the "end"
(sideEffect is key S-x->S))
* has natural branching constructs -- not just serial stream processing.
* supports an execution structure that is a graph, not a DAG (e.g.
{{repeat()}}, {{back()}}, ...)
* fundamentally an arbitrary execution graph with {{jump()}} (low-level,
but there)
* this provides turing completeness as we have a non-serial "program
counter" (the step ID is analogous to instruction's location in RAM and a
traverser can jump to any step ID it wants). Moreover we have two random access
memories ({{sack}} (local) and {{sideEffect}} (global)).
* can be easily expressed in any host language as its represented using a
fundamental concept in all programming languages -- fluent function chaining
(monoid state modulation)
* for JVM languages, simply {{import Traversal}} and use the syntax of the
importing language (e.g. Jython, Rhino, Groovy, Scala, Clojure, etc.)
* can be used as a database query language (and/)or an arbitrary data flow
language (given this proposal).
* has numerous execution engines
(Giraph,MapReduce,Spark,Fulgora,TinkerGraph,...) with different time/space
complexities.
* has remote execution functionality via GremlinServer (with monitoring).
* ...and, native support for the most complex data structure there is, the
graph (i.e. {{outE}}, {{in}}, etc.)
Its mind boggling actually... I can't think of anything else like this.
[~mbroecheler] @dkuppitz [~spmallette] @joshsh
> [Proposal] Provide a way to process arbitrary objects with GraphComputer
> ------------------------------------------------------------------------
>
> Key: TINKERPOP3-571
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-571
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.0.0-incubating
> Reporter: Marko A. Rodriguez
> Assignee: Marko A. Rodriguez
>
> I want to be able to do this in OLAP:
> {code}
> __(12,21,3,4,75).is(gt,10).sum()
> {code}
> An idea is this... For any {{Iterator<Object>}}, we need to be able to
> generate a Graph where:
> {code}
> g.addVertex(id,12)
> g.addVertex(id,21)
> g.addVertex(id,3)
> g.addVertex(id,4)
> g.addVertex(id,75)
> {code}
> ...and then the start of the OLAP traversal has a "hidden prefix" of
> {{g.V.id}} thus, behind the scenes, what is being executed is:
> {code}
> g.V.id.is(gt,10).sum()
> {code}
> If we can make OLAP object processing just as natural as graph processing,
> then I don't see why Gremlin is not the craziest functional language to date:
> * single machine or distributed
> * supports non-terminal sideEffects (i.e. {{groupCount()}} is not the "end"
> (sideEffect is key S-x->S))
> * has natural branching constructs -- not just serial stream processing.
> * supports an execution structure that is a graph, not a DAG (e.g.
> {{repeat()}}, {{back()}}, ...)
> * fundamentally an arbitrary execution graph with {{jump()}}
> (low-level, but there)
> * this provides turing completeness as we have a non-serial "program
> counter" (the step ID is analogous to instruction's location in RAM and a
> traverser can jump to any step ID it wants). Moreover we have two random
> access memories ({{sack}} (local) and {{sideEffect}} (global)).
> * can be easily expressed in any host language as its represented using a
> fundamental concept in all programming languages -- fluent function chaining
> (monoid state modulation)
> * for JVM languages, simply {{import Traversal}} and use the syntax of
> the importing language (e.g. Jython, Rhino, Groovy, Scala, Clojure, etc.)
> * can be used as a database query language (and/)or an arbitrary data flow
> language (given this proposal).
> * has numerous execution engines
> (Giraph,MapReduce,Spark,Fulgora,TinkerGraph,...) with different time/space
> complexities.
> * has remote execution functionality via GremlinServer (with monitoring).
> * ...and, native support for the most complex data structure there is, the
> graph (i.e. {{outE}}, {{in}}, etc.)
>
> Its mind boggling actually... I can't think of anything else like this.
> [~mbroecheler] @dkuppitz [~spmallette] @joshsh
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
