Mailing-List: contact dev-help@giraph.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@giraph.apache.org
Received-SPF: unknown (athena.apache.org: error in processing during lookup of
 prvs=677634f10e=alessandro@fb.com)
From: Alessandro Presta <alessandro@fb.com>
To: "dev@giraph.apache.org" <dev@giraph.apache.org>
Subject: Re: [jira] [Created] (GIRAPH-547) Allow in-place modification of
 edges
Thread-Topic: [jira] [Created] (GIRAPH-547) Allow in-place modification of
 edges
Thread-Index: AQHOFrZpGprKVXyuRk6GOoc0atvs25iXFxiA//99kgA=
Date: Tue, 5 Mar 2013 05:19:44 +0000
Message-ID: 
 <566834A0CA4ED742A53644FF331260D4380EAA34@PRN-MBX02-5.TheFacebook.com>
In-Reply-To: 
 <CAH3ch-aS0fmgdVA0tenEKd5zRHV-=CfRkjMicTiSw0nSY4x3zQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <160CD769940A7A4E804261EED165ED70@fb.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Jiadong,

Yes, that's not recommended because some optimized implementations reuse
the same Edge object, so whatever change you make has no effect on the
underlying data.
It happens to work when using EdgeListVertex because there we actually
have one Edge object per edge.

Alessandro

On 3/4/13 9:06 PM, "Jiadong Wu" <jwu65@gatech.edu> 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)
><jira@apache.org> 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 =3D getEdges().iterator(); it.hasNext();) {
>>   Edge<I, E> edge =3D 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