Hi guys, I may not understand this issue clearly, but if we do want in-place modification why not simply use edge.getValue().set(newValue) instead? I used this method a lot in my code, where the edge value is a LongWritable. Is there any potential problem? Thanks,
Jiadong On Fri, Mar 1, 2013 at 2:53 PM, Alessandro Presta (JIRA) <[email protected]> wrote: > Alessandro Presta created GIRAPH-547: > ---------------------------------------- > > Summary: 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 this is needed: 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
