This question pertains to the calling of vertices in Igraph.
Lets say we have a directed graph
g<-graph(c(1:10),directed=T)
and i want to find the vertices pointing to vertex 2.
Lets say you want to find the vertices pointed "to" vertex 1.
Why won't using the "to" condition work
V(g)[to(1)]
but rather this?
V(g)[nei(1,"to")]
It works for me?
> g<-graph(c(1:10),directed=T)
> V(g)[to(1)]
Vertex sequence:
[1] 2
> V(g)[nei(1,"to")]
Vertex sequence:
[1] 2
Personally I like working with edgelists. Alternatively you could do it like this:
# Get edgelist:
E <- get.edgelist(g)
# To 1 in directed graph:
E[E[,2]==1,1]
# Connected to 1 in undirected graph:
c(E[E[,2]==1,1],E[E[,1]==1,2])
to works only with edge sequences; e.g., E(g)[to(1)] gives you all the edges that point to vertex 1. IMHO this is quite logical since vertices do not "point" anywhere (the edges do) so it does not make sense to use from or to.
Also, the "official" way of using nei is nei(1, "out") and not nei(1, "to") although it could be the case that "to" works as well. You can use outnei(1) as well.
Disclaimer: I am one of the authors of igraph although I did not write the R interface so there might be a better reason than the one I explained above.
Related
I am trying to port code from python NetworkX to R igraph. In NetworkX there is a function with the name has_path that finds if two vertices have a path. I want to find in an efficient way all the vertices of a graph that don't have an edge between them but they have a path.
I think you can use the code below to check if there is a path from vertex V1 to V2 (the graph can be directed or undirected)
c(!is.infinite(distances(g, V1, V2, mode = "out")))
If you need to check this repeatedly in an undirected graph, simply break it into connected components and check if both vertices are within the same component. This will be very efficient, as the components need to be found only once.
See the components function. It gives you a membership vector. You need to check if the position corresponding to the two vertices has the same value (same component index).
If the graph is directed, the simplest solution is the one posted by #ThomasIsCoding. This is perfectly fine for a one-time check. Speeding up repeated checks is more trouble and warrants its own question.
Is it possible to find all possible directed graphs given a pair of vertices and the information that an edge exists between them? For example if we know the vertices with edge pairs like
1 2
2 3
1 3
The possible directed graphs will be:
1→2, 2→3, 1→3
1→2, 2→3, 3→1
1→2, 3→2, 1→3
1→2, 3→2, 3→1
2→1, 2→3, 1→3
2→1, 2→3, 3→1
2→1, 3→2, 1→3
2→1, 3→2, 3→1
What data-structure to be used here to work with? What can be the working logic?
I was thinking of using adjacency matrix data structure and compute all possible adjacency matrix. Each adjacency matrix will represent a graph. We can use the graph as and when needed for tasks like checking whether cycle is present or not etc.
Apologies that this is more of a discussion than a programming question, but any help will be appreciated
You could maintain one undirected graph data structure G and work with the knowledge that the existence of an edge (u,v) means that there is only one directed edge in a particular instance of digraph possibility D.
If you want to maintain all possible digraphs separately, you would need 2^m many of them, where m is the number of edges. If the vertices and edges are always the same and only the direction is the invariant, then you could maintain 2^m bit-strings, each of length m. Each bit has a 0 or 1 depending on whether the edge (u,v) it corresponds to is u-->v or v<--u. Use the bit string to give direction to the undirected graph suggested above. You just need to generate all 2^m bit strings. Not very efficient... but you can't do better if you need to work with all possibilities.
You could use the bit string to construct a digraph. But, it would be more memory efficient at least to maintain only one bit-string per 'graph' rather than repeating the entire graph data structure with only directional changes. Record bit strings in a hash table: use each edge as a key and then bit value 0/1 depending on direction. Any graph traversal of one of the many possible digraphs D works on undirected G. Then in constant time you can check for incident (undirected) edges of a vertex, which are outgoing/incoming in D. So traversals can occur just as quickly by maintaining only 1 graph object and 1 bit hash table of size 2^m (rather than 2^m graph objects).
I want to set the edge attributes of a certain range of edges in a graph based on the values of the nodes they connect (in R igraph of course).
When I retrieve a certain edge in my graph object, I am served with an edge sequence object:
E(g)[1]
# + 1/2080 edge (vertex names):
# [1] 35->1
class(E(g)[1])
# [1] "igraph.es"
How can I get to the actual edges from that edge sequence? The only relevant function I have found is as_ids:
as_ids(E(g)[1])
# [1] "35|1"
Then I have to split the string to get to the node ids, convert the ids to integers, fetch the nodes using the V(g)[x] notation, check the attributes I am interested in and finally set the edge attribute.
This is an impractical and wasteful process. Is there any more straightforward way to do the same?
I know the %--% notation and in certain cases it solves my issue by allowing me to filter the edges based on node attributes in advance. But in many other cases that notation doesn't help (when edge attribute values have a more complex relationship with node attributes), and I wonder if there is a more general way to get from one edge sequence to the corresponding pair of nodes.
You can use the ends function to get to the vertices:
ends(g, E(g)[1])
I am drawing an undirected graph with Graphviz that has redundant edges, (e.g. A -- B and B -- A). I would like to see only one line between the two vertices, regardless of whether there is a redundant reverse edge in the data. My question is, is there a way to do this with Graphviz, without having to use some other tool/code first to remove the redundant edges? I have tried graph [splines=false]; without any success. Below is a minimal example:
graph G {
graph [splines=false];
node [shape=point];
a -- b;
b -- a;
}
And the output:
What I want as output is:
despite the redundant edges that may exist in the specified graph.
You may try setting nodesep to 0 :
... this affects the spacing between loops on a single node, or multiedges between a pair of nodes.
Not sure if nodesep is completely set to 0, because in the documentation the minimum value indicated is 0.02. A quick test seems to be ok, though.
Try "strict graph G { ... }"
A strict graph or digraph disallows parallel edges.
Stephen North north#graphviz.org
I want to generate a sequence of the number of vertices in all graphs which each edge has the same number of leaving edges. I dont have to generate the whole sequence. Let's say the first 50 if exists.
I want:
Input: the number of edges leaving each vertex
Output: a sequence of the number of vertices
So far, I have looked at complete graphs. Complete graphs with n vertices always have n-1 edges leaving each vertex. But there are other kinds of graphs that have this property. For example, some polyhedrons, such as snub dodecahedron and truncated icosidodecahedron have this property.
How should I approach my problem?
I think you mean regular graphs:
http://en.wikipedia.org/wiki/Regular_graph
http://mathworld.wolfram.com/RegularGraph.html
I made a regular graph generator which isn't flawless by the way:
once you generate the nodes, say from 1 to n. You want regularity r.
For node 1, make connections to the following nodes until you reach degree r for node 1.
For node 2 you already have degree 1 (because of node 1), you connect again to further nodes until you reach degree r for node 2 too. And this way till the last node.
The flaw is that you can't define an r-regular graph for any number of nodes. The algorithm mentioned doesn't detect that, so some errors may occur. Also, this isn't a random r-regular graph generator, but instead give one possible solution.
I'm not much of an explainer, so please ask if the description lacks somewhere.