Mailing-List: contact user-help@giraph.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@giraph.apache.org
Received-SPF: pass (athena.apache.org: domain of ssc.open@googlemail.com
 designates 209.85.214.42 as permitted sender)
Message-ID: <51118289.40504@apache.org>
Date: Tue, 05 Feb 2013 23:07:05 +0100
From: Sebastian Schelter <ssc@apache.org>
Reply-To: ssc@apache.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: user@giraph.apache.org
Subject: Re: GreenMarl
References: 
 <CAGJnLiuhcwSVmot+op0m4ae5SQf=aMwDTcOBdyYiwdRKPMePTw@mail.gmail.com>
 <5111666C.8070406@apache.org>
 <CAMOYj4D-3_HZuMV3BQ0LH6n9TpkWERd9TGbdBvSWVabVpw12zw@mail.gmail.com>
 <AC7A5767-1EEF-466F-BE82-EFCEF9CB740F@cs.cmu.edu>
 <17559C56-6EEA-45D1-AF47-5A4B0194044C@cs.cmu.edu>
In-Reply-To: <17559C56-6EEA-45D1-AF47-5A4B0194044C@cs.cmu.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Aapo,

No worries. I think the future lies in easy to use languages or
paradigms that can be compiled to or ran in the system of the users
choice. For some people and problems this might be GraphChi on a single
machine, for others it might Giraph on a cluster. Might be good to have
you and the giraph community exchange ideas from time to time :)

Best,
Sebastian


On 05.02.2013 23:03, Aapo Kyrola wrote:
> 
> Apologies about posting this email to the group  -it  was meant directly to Jan.
> 
> Aapo
> 
> On Feb 5, 2013, at 12:34 PM, Aapo Kyrola <akyrola@cs.cmu.edu> wrote:
> 
>> Hi Lugt,
>>
>> Have you considered a Graphchi code generator for GreenMarl? I like the BFS abstraction!
>>
>> Aapo 
>>
>>
>> Sent from my iPhone
>>
>> On Feb 5, 2013, at 12:19 PM, Jan van der Lugt <janlugt@gmail.com> wrote:
>>
>>> Green-Marl comes with an implementation of betweenness centrality and allows you to compile it to Giraph code:
>>> https://github.com/stanford-ppl/Green-Marl
>>>
>>> The BC algorithm:
>>> https://github.com/stanford-ppl/Green-Marl/blob/master/apps/src/bc_random.gm
>>>
>>> On Tue, Feb 5, 2013 at 8:07 PM, Sebastian Schelter <ssc@apache.org> wrote:
>>> Hello Pradeep,
>>>
>>> the standard betweeness and closeness measures do not scale to large
>>> graphs per se, as they require computation of all shortest paths, where
>>> even the result is quadratic in the number of vertices and therefore
>>> intractable.
>>>
>>> U Kang has done some interesting work on finding scalable substitutes
>>> for these measures:
>>>
>>> "Centralities in large graphs"
>>> http://www.cs.cmu.edu/~ukang/papers/CentralitySDM2011.pdf
>>>
>>> These algorithms should be relatively simple to implement in Giraph, we
>>> had some students prototype them in a university course last year.
>>>
>>> Best,
>>> Sebastian
>>>
>>>
>>> On 05.02.2013 20:23, pradeep kumar wrote:
>>>> Hi all,
>>>>
>>>> Actually we are working on finding centrality for nodes in a graph
>>>> (betweenness , closeness and in-out) so far we have just implemented for
>>>> in-out and currently working on implementation of brandes alg for finding
>>>> betweenness centrality which requires finding shortest path for each node
>>>> to every node.
>>>>
>>>> Actually right now problem we are facing is passing all-nodes list at
>>>> beginning for computation of shortest paths.
>>>>
>>>> 1) Is their a method availabe to achieve this. we are using giraph 1.0..(we
>>>> couldnt find method for support in file library)
>>>>
>>>> 2) Is it possible compute shortest path for node to every other in single
>>>> superstep
>>>>
>>>> 3) or can we use master compute for such computation
>>>>
>>>> And is there any other way we can compute betweeness for nodes efficiently
>>>> in giraph..
>>>>
>>>> Any suggestion..and..Thanks for help in advance..
>>>>
>>>
>>>
> 
> Aapo Kyrola
> Ph.D. student, http://www.cs.cmu.edu/~akyrola
> GraphChi: Big Data - small machine: http://graphchi.org
> twitter: @kyrpov
> 
>