Thank you guys for the explanation. I actually didn't notice that in current API the edge is immutable, and it's lucky that the EdgeListVertex didn't fail me. I think the proposed mutable iterator would make so much sense to many applications. At least to the flow problem that I am working on where the edge value is changing almost constantly.
Jiadong On Tue, Mar 5, 2013 at 12:11 PM, Alessandro Presta <[email protected]> wrote: > Eli, please read my other answer on why this is almost never correct (we > reuse edges in the iterators in many implementations). > After we address this JIRA, we should be able to do something similar to what > Jiadong said (and also remove edges) via the mutable iterator. > > Sent from my iPhone > > On Mar 5, 2013, at 9:02 AM, "Eli Reisman" <[email protected]> wrote: > >> Thanks for the suggestion. I think the issue we're hashing out here has >> more to do with which API choices force which implementation constraints on >> the framework. But yes, the method you use in your code is sound! >> >> On Mon, Mar 4, 2013 at 9:06 PM, Jiadong Wu <[email protected]> wrote: >> >>> 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 >>>
