Return-Path: X-Original-To: apmail-giraph-user-archive@www.apache.org Delivered-To: apmail-giraph-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4C4FBE5C3 for ; Tue, 5 Feb 2013 20:20:06 +0000 (UTC) Received: (qmail 75338 invoked by uid 500); 5 Feb 2013 20:20:06 -0000 Delivered-To: apmail-giraph-user-archive@giraph.apache.org Received: (qmail 75283 invoked by uid 500); 5 Feb 2013 20:20:06 -0000 Mailing-List: contact user-help@giraph.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@giraph.apache.org Delivered-To: mailing list user@giraph.apache.org Received: (qmail 75275 invoked by uid 99); 5 Feb 2013 20:20:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Feb 2013 20:20:06 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of janlugt@gmail.com designates 209.85.223.177 as permitted sender) Received: from [209.85.223.177] (HELO mail-ie0-f177.google.com) (209.85.223.177) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Feb 2013 20:19:59 +0000 Received: by mail-ie0-f177.google.com with SMTP id 16so790609iea.8 for ; Tue, 05 Feb 2013 12:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=hbrEfr+vmUKCEVn/wf1rGnTNB6xEjoWS3rgswljs4aM=; b=ePni3e4XreMKoQUEChTO4EN8gX0S6M6+q6rl0xKRHIr6G+VXWVqJXmZmLDgqujLCYn UImHSRx9/f7VxvH9oJcAy5CnV6JKIFE2WlVn7iJDuzvB5p7RfKqo0dOh7gjDDrC7P5iv wL0gbkwlZQDE3heFc9Mzx8y3otS2o5A068sawKuyzCSb4outYGSqVmQTx4oJmREUquhR x54bblhtt57pP8qa5lB0DNaRgttxem/72Jadwk7EDErVYBv5uMrVFDV6FSh3K/fc9+pq EPBwaVUnTLMvaPZ3TSBFJs4ikQXXXdgwHw8MxOEU99PDTBqUIsFK3LxXvEixgNHKmMJz tlJA== MIME-Version: 1.0 X-Received: by 10.50.135.100 with SMTP id pr4mr695220igb.37.1360095579010; Tue, 05 Feb 2013 12:19:39 -0800 (PST) Received: by 10.50.191.227 with HTTP; Tue, 5 Feb 2013 12:19:38 -0800 (PST) In-Reply-To: <5111666C.8070406@apache.org> References: <5111666C.8070406@apache.org> Date: Tue, 5 Feb 2013 20:19:38 +0000 Message-ID: Subject: Re: Trying to implement program to find betweenness centrality in giraph From: Jan van der Lugt To: user@giraph.apache.org, ssc@apache.org Content-Type: multipart/alternative; boundary=e89a8f83ac2dd8f7db04d4ffed66 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8f83ac2dd8f7db04d4ffed66 Content-Type: text/plain; charset=ISO-8859-1 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 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.. > > > > --e89a8f83ac2dd8f7db04d4ffed66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Green-Marl comes with an implementation of betweenness centrality and allow= s you to compile it to Giraph code:
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<= br>
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 f= or
> in-out and currently working on implementation of brandes alg for find= ing
> betweenness centrality which requires finding shortest path for each n= ode
> to every node.
>
> Actually right now problem we are facing is passing all-nodes list at<= br> > 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 sin= gle
> superstep
>
> 3) or can we use master compute for such computation
>
> And is there any other way we can compute betweeness for nodes efficie= ntly
> in giraph..
>
> Any suggestion..and..Thanks for help in advance..
>


--e89a8f83ac2dd8f7db04d4ffed66--