Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A109B9F23 for ; Sun, 26 Feb 2012 23:48:38 +0000 (UTC) Received: (qmail 19266 invoked by uid 500); 26 Feb 2012 23:48:38 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 18896 invoked by uid 500); 26 Feb 2012 23:48:37 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 18888 invoked by uid 99); 26 Feb 2012 23:48:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 26 Feb 2012 23:48:37 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.212.43] (HELO mail-vw0-f43.google.com) (209.85.212.43) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 26 Feb 2012 23:48:33 +0000 Received: by vbbfq11 with SMTP id fq11so2999150vbb.30 for ; Sun, 26 Feb 2012 15:48:12 -0800 (PST) Received-SPF: pass (google.com: domain of jcarman@carmanconsulting.com designates 10.220.232.10 as permitted sender) client-ip=10.220.232.10; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jcarman@carmanconsulting.com designates 10.220.232.10 as permitted sender) smtp.mail=jcarman@carmanconsulting.com Received: from mr.google.com ([10.220.232.10]) by 10.220.232.10 with SMTP id js10mr6497270vcb.53.1330300092264 (num_hops = 1); Sun, 26 Feb 2012 15:48:12 -0800 (PST) Received: by 10.220.232.10 with SMTP id js10mr5198699vcb.53.1330300092203; Sun, 26 Feb 2012 15:48:12 -0800 (PST) MIME-Version: 1.0 Sender: jcarman@carmanconsulting.com Received: by 10.220.2.129 with HTTP; Sun, 26 Feb 2012 15:47:52 -0800 (PST) In-Reply-To: <4F4AB523.9010808@dia.uniroma3.it> References: <4F49381F.3020207@dia.uniroma3.it> <5C9CD62B-8BF0-46B4-8EA8-410BCB68D6B6@apache.org> <4F4AB523.9010808@dia.uniroma3.it> From: James Carman Date: Sun, 26 Feb 2012 18:47:52 -0500 X-Google-Sender-Auth: Otlq-f2UkNxxvjgdIoy7ppk3g2w Message-ID: Subject: Re: [graph] Doubts on DFS algorithm implementation To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkhCGD9M/QIa2Khtax6zvwZDY3tWh8T9EEEj3qz6SB4iTGXZmwPJd/zGTsgoYKGd16faZ9n On Sun, Feb 26, 2012 at 5:41 PM, Claudio Squarcella wrote: > the method "discoveryEdge" currently tells whether or not the algorithm > should explore a subtree/branch and add related vertices to the stack/queue. > So I see no conflict in the implementation. Maybe you are saying that the > edge should be explored *right before* the vertex it leads to -- but why? > AFAIK a standard graph search is only concerned with *vertices*. In that > sense "finishEdge" becomes useless, as the responsibility for returning > prematurely is entirely covered by "finishVertex". Am I raving mad? :-) > Well, you bring up a good point. Are we concerned with "visiting" both the edges and the vertices? Typically, I just care about the vertices when doing dfs/bfs on graphs, but I can see how one might want to do both. Also, I don't know if we have an abstraction for this, but the order in which you add your connected vertices can be important, too (might want to do a "greedy" bfs/dfs). Unfortunately, I've not had much time to dig into this code, but I would really love to find some time. I like this kind of stuff. It makes me feel like all that discrete mathematics stuff I studied wasn't a complete waste! :) In the "business" world, you don't get to play with this stuff that often. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org