giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Reisman <apache.mail...@gmail.com>
Subject Re: [jira] [Commented] (GIRAPH-547) Allow in-place modification of edges
Date Sat, 02 Mar 2013 20:43:54 GMT
I am liking the iterator idea a lot.

On Fri, Mar 1, 2013 at 1:05 PM, Alessandro Presta (JIRA) <jira@apache.org>wrote:

>
>     [
> https://issues.apache.org/jira/browse/GIRAPH-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590936#comment-13590936]
>
> Alessandro Presta commented on GIRAPH-547:
> ------------------------------------------
>
> Another follow-up from a conversation with Maja: we could add a
> MutableVertexEdges interface which can return the mutable iterator.
> That way, we can optimize in-place modification in cases like primitive
> arrays (where you have random access) and Java collections (where the
> mutable edge iterable is the same as the immutable one).
>
> I will work on this after the API redesign.
>
> > Allow in-place modification of edges
> > ------------------------------------
> >
> >                 Key: GIRAPH-547
> >                 URL: https://issues.apache.org/jira/browse/GIRAPH-547
> >             Project: Giraph
> >          Issue Type: New Feature
> >            Reporter: Alessandro Presta
> >            Assignee: Alessandro Presta
> >
> > This is a somewhat long term item.
> > Because of some optimized edge storage implementations (byte array,
> primitive array), we have a contract with the user that Edge objects
> returned by getEdges() are read-only.
> > One concrete example where in-place modification would be useful: in the
> weighted version of PageRank, you can store the weight sum and normalize
> each message sent, or you could more efficiently normalize the out-edges
> once in superstep 0.
> > The Pregel paper describes an OutEdgeIterator that allows for in-place
> modification of edges. I can see how that would be easy to implement in
> C++, where there is no need to reuse objects.
> > Giraph "unofficially" supports this if one is using generic collections
> to represent edges (e.g. ArrayList or HashMap).
> > It may be trickier in some optimized implementations, but in principle
> it should be doable.
> > One way would be to have some special MutableEdge implementation which
> calls back to the edge data structure in order to save modifications:
> > {code}
> > for (Edge<I, E> edge : getEdges()) {
> >   edge.setValue(newValue);
> > }
> > {code}
> > Another option would be to add a special set() method to our edge
> iterator, where one can replace the current edge:
> > {code}
> > for (EdgeIterator<I, E> it = getEdges().iterator(); it.hasNext();) {
> >   Edge<I, E> edge = it.next();
> >   edge.setValue(newValue);
> >   it.set(edge);
> > }
> > {code}
> > We could actually implement the first version as syntactic sugar on top
> of the second version (the special MutableEdge would need a reference to
> the iterator in order to call set(this)).
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message