[jira] [Comment Edited] (TINKERPOP-1849) Provide a way to fold() with an index
[
https://issues.apache.org/jira/browse/TINKERPOP-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680108#comment-16680108
]
Daniel Kuppitz edited comment on TINKERPOP-1849 at 12/4/18 9:58 PM:
I don't know when I will start to work on this, so - as a reminder - here are
just the thoughts from our latest discussion:
We should only implement a local version of this step, because
# it's not too much to ask a user to do the {{fold()}}
# by explicitly using {{fold()}} the user is made aware of the memory
consumption
# it will just work in OLTP and OLAP
This is how could look like:
{noformat}
gremlin> g.V().index()
==>[v[1], 0]
==>[v[2], 0]
==>[v[3], 0]
==>[v[4], 0]
==>[v[5], 0]
==>[v[6], 0]
gremlin> g.V().fold().index()
==>[[v[1],0],[v[2],1],[v[3],2],[v[4],3],[v[5],4],[v[6],5]]
gremlin> g.V().fold().index().with(WithOptions.indexer, WithOptions.map)
==>[0:v[1],1:v[2],2:v[3],3:v[4],4:v[5],5:v[6]]
{noformat}
was (Author: dkuppitz):
I don't know when I will start to work on this, so - as a reminder - here are
just the thoughts from our latest discussion:
We should only implement a local version of this step, because
# it's not too much to ask a user to do the {{fold()}}
# by explicitly using {{fold()}} the user is made aware of the memory
consumption
# it will just work in OLTP and OLAP
This is how could look like:
{noformat}
gremlin> g.V().index()
==>[v[1], 0]
==>[v[2], 0]
==>[v[3], 0]
==>[v[4], 0]
==>[v[5], 0]
==>[v[6], 0]
gremlin> g.V().fold().index()
==>[[v[1],0],[v[2],1],[v[3],2],[v[4],3],[v[5],4],[v[6],5]]
gremlin> g.V().fold().index().by('e').by('i')
==>[[e:v[1],i:0],[e:v[2],i:1],[e:v[3],i:2],[e:v[4],i:3],[e:v[5],i:4],[e:v[6],i:5]]
{noformat}
> Provide a way to fold() with an index
> -
>
> Key: TINKERPOP-1849
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1849
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.0
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Major
>
> In Groovy you can call {{withIndex()}} to generate output like this:
> {code}
> gremlin> g.V().fold().next().withIndex()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> We can currently simulate this with Gremlin via:
> {code}
> gremlin>
> g.V().project("a","b").by().by(select("x").count(local)).store("x").map(union(select('a'),
> select('b')).fold()).fold().next()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> but it's not easy to follow, efficient, or potentially foolproof. Perhaps we
> can add an option to {{fold()}} that would take an enum of "fold operators".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TINKERPOP-1849) Provide a way to fold() with an index
[
https://issues.apache.org/jira/browse/TINKERPOP-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16282342#comment-16282342
]
Marko A. Rodriguez edited comment on TINKERPOP-1849 at 12/7/17 7:06 PM:
After bragging to [~dkuppitz] about my solution, he said: "Does it work on
GraphComputer?" I immediately thought: "no" and tested it and it doesn't. Why?
{{FoldStep}} is a {{ReducingBarrierStep}} and thus, can only work with
associative and commutative operations. {{addWithIndex}} is not. It requires a
serial ordering during "folding" in order to get an index. Thus, this raises
two solutions:
Do we provide a "flag" on {{Operators}} to say whether they are associative and
commutative?
1. If so, then if it is not, then all reduction must happen on the master
traversal.
2. Or, simply through a {{ComputerVerificationException}} is such operators
are used.
The more general problem would be provided lambdas that are NOT commutative nor
associative. How is Gremlin to know?
was (Author: okram):
After bagging to [~dkuppitz] about my solution, he said: "Does it work on
GraphComputer?" I immediately thought: "no" and tested it and it doesn't. Why?
{{FoldStep}} is a {{ReducingBarrierStep}} and thus, can only work with
associative and commutative operations. {{addWithIndex}} is not. It requires a
serial ordering during "folding" in order to get an index. Thus, this raises
two solutions:
Do we provide a "flag" on {{Operators}} to say whether they are associative and
commutative?
1. If so, then if it is not, then all reduction must happen on the master
traversal.
2. Or, simply through a {{ComputerVerificationException}} is such operators
are used.
The more general problem would be provided lambdas that are NOT commutative nor
associative. How is Gremlin to know?
> Provide a way to fold() with an index
> -
>
> Key: TINKERPOP-1849
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1849
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.0
>Reporter: stephen mallette
>
> In Groovy you can call {{withIndex()}} to generate output like this:
> {code}
> gremlin> g.V().fold().next().withIndex()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> We can currently simulate this with Gremlin via:
> {code}
> gremlin>
> g.V().project("a","b").by().by(select("x").count(local)).store("x").map(union(select('a'),
> select('b')).fold()).fold().next()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> but it's not easy to follow, efficient, or potentially foolproof. Perhaps we
> can add an option to {{fold()}} that would take an enum of "fold operators".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
