Skip to content
This repository was archived by the owner on Oct 8, 2021. It is now read-only.

Conversation

CarloLucibello
Copy link
Contributor

neighborhood(g, v, d) returns a vector containing the vertices in g up to distance d from v

This is the most efficient version it come to me without thinking too hard on it. Any suggestion for improvements in performance and documentation is welcome

Also its positioning in connectivity.jl could be reconsidered

@codecov-io
Copy link

Current coverage is 97.83%

Merging #329 into master will increase coverage by +0.01% as of 5f19738

Powered by Codecov. Updated on successful CI builds.

newneigs = Set{Int}()
for i in ∂neig
for j in fneig(g, i)
if j neig
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't need this test, since neig is a set, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still need it because I wouldn't want to add to ∂neig if it's already in neig

@sbromberger
Copy link
Owner

You're reading my mind, @CarloLucibello - I had plans to code this up this week. Looks good except for one question I had in the code (see the line notes).

Other question: Couldn't you use BFS for this, or something like gdistances? Probably not as efficient since you have to touch each node, but you could code up a visitor/traversal to do this relatively quickly.

@jpfairbanks
Copy link
Contributor

@sbromberger I was thinking the same thing. You could use a Visitor Type whose definition of discover_vertex that checked that

if colormap[v] < d
    # normal BFS behavior
else
    # we have reached the d-th neighborhood break loop
    return false
end

This would give you the d-neighborhood without using Set operations and also give you all neighborhoods up to radius d in one shot.

Modifying the TreeBFSVisitor would use nv memory but that memory would be reusable in case someone wanted to get lots of d-neighborhoods.

@CarloLucibello
Copy link
Contributor Author

I don't think it is reasonable to have this local computation to scale with the size of the graph. Even if we reuse memory in the case of many calls, it would still be O(nv) since we have to reset the memory.

Could it be feasible to implement a "local" visitor?

@sbromberger
Copy link
Owner

Just thinking out loud here - I think that if any of the examine_* functions return false, it will stop the traversal. If this is the case, you could have an examine_neighbor function that just checked the geodetic distance from it to some source, and returned false if it exceeded it. This shoud short-circuit the rest of the BFS.

@jpfairbanks
Copy link
Contributor

Yeah that's right. We need to change the colormap to a sparse representation. Either a Dict or some AbstractArray.

function breadth_first_visit_impl!(
    graph::SimpleGraph,   # the graph
    queue::Vector{Int},              # an (initialized) queue that stores the active vertices
    colormap::Vector{Int},         # an (initialized) color-map to indicate status of vertices
    visitor::SimpleGraphVisitor) # the visitor

The visitor for this case could be:

immutable LocalVisitor <: SimpleGraphVisitor
    dists::Dict{Int, Int}
end

We could also build egonets using the following visitor type.

immutable EgonetVisitor{Graph} <: SimpleGraphVisitor
    graph::Graph
    dists::Dict{Int, Int}
end
immutable DiEgonetVisitor{Graph} <: SimpleGraphVisitor
    graph::DiGraph
    dists::Dict{Int, Int}
end

@CarloLucibello
Copy link
Contributor Author

closing this in favor of #332

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants