Creating random directed edges between nodes in nodejs - node.js
Say I have a graph with several nodes. I need to design an algorithm which randomly creates directed edges between nodes while satisfying the following conditions:
each node has exactly one edge pointing to it
each node has exactly one edge pointing away from it
no node points to itself
For example, say my graph had three nodes, the following scenarios would be acceptable:
Node A points to B, B points to C, C points to A
Node A points to C, C points to B, B points to A
Does anyone know what the most efficient way of doing this would be? I'm using nodejs btw. For argument's sake, we can say that I am starting with an array containing the names of the nodes.
Thanks
lets define you have array of vertex: V = {v}; |V| = N, now we can shuffle array of vertex by using any random shuffle algorithm.
V = [v_1, v_2, v_3,..,v_n]
Now we can define N-1 edges E, where e[i] = (v[i] to v[i + 1]), and the last vertex will be (v[N-1] to v[0])
Related
How to convert a bipartite graph into no bipartite
I've been trying to do this for a long time without success, so I'd better ask you. First of all, I'm working on python 3 and networkx. I have a bipartite graph as the image A, in which there are two types of nodes according to their 'group' attribute (group='R' and group='X'). Also, some relationships are reversible, as R4, and some are not (so I guess we would have to unfold the node in those cases). What I need is to leave only the nodes of the R group and eliminate the X ones, but keeping the relations between them. That is, convert the green nodes into edges and keep a graph of only blue nodes. Ohhh please!!, Can someone give me a hand? Any help would be very welcome. Thank you in advance wholeheartedly! GRAPH IMAGE HERE: https://media.springernature.com/full/springer-static/image/art%3A10.1038%2Fs41540-018-0067-y/MediaObjects/41540_2018_67_Fig1_HTML.png
Go over nodes of the graph, if the node is green add an edge between all its neighbours (which will only be blue). At the end remove all the green nodes. to_remove = [] for node in G.nodes(data = True): if node[1]["type"] == "Green": ## check if the node is green to_remove.append(node[0]) ## go over all neighbours of the node and add an edge between them neighbours = list(G.neighbors(node[0])) for i in range(0, len(neighbours)-1): for j in range(i+1, len(neighbours)): G.add_edge(neighbours[i],neighbours[j]) ## remove the green nodes G.remove_nodes_from(to_remove)
TSP / CPP variant - subtour constraint
I'm developing an optimization problem that is a variant on Traveling Salesman. In this case, you don't have to visit all the cities, there's a required start and end point, there's a min and max bound on the tour length, you can traverse each arc multiple times if you want, and you have a nonlinear objective function that is associated with the arcs traversed (and number of times you traverse each arc). Decision variables are integers, how many times you traverse each arc. I've developed a nonlinear integer program in Pyomo and am getting results from the NEOS server. However I didn't put in subtour constraints and my results are two disconnected subtours. I can find integer programming formulations of TSP that say how to formulate subtour constraints, but this is a little different from the standard TSP and I'm trying to figure out how to start. Any help that can be provided would be greatly appreciated. EDIT: problem formulation 50 arcs , not exhaustive pairs between nodes. 50 Decision variables N_ab are integer >=0, corresponds to how many times you traverse from a to b. There is a length and profit associated with each N_ab . There are two constraints that the sum of length_ab * N_ab for all ab are between a min and max distance. I have a constraint that the sum of N_ab into each node is equal to the sum N_ab out of the node you can either not visit a node at all, or visit it multiple times. Objective function is nonlinear and related to the interaction between pairs of arcs (not relevant for subtour). Subtours: looking at math.uwaterloo.ca/tsp/methods/opt/subtour.htm , the formulation isn't applicable since I am not required to visit all cities, and may not be able to. So for example, let's say I have 20 nodes and 50 arcs (all arcs length 10). Distance constraints are for a tour of exactly length 30, which means I can visit at most three nodes (start at A -> B -> C ->A = length 30). So I will not visit the other nodes at all. TSP subtour elimination would require that I have edges from node subgroup ABC to subgroup of nonvisited nodes - which isn't needed for my problem
Here is an approach that is adapted from the prize-collecting TSP (e.g., this paper). Let V be the set of all nodes. I am assuming V includes a depot node, call it node 1, that must be on the tour. (If not, you can probably add a dummy node that serves this role.)
Let x[i] be a decision variable that equals 1 if we visit node i at least once, and 0 otherwise. (You might already have such a decision variable in your model.)
Add these constraints, which define x[i]:
x[i] <= sum {j in V} N[i,j] for all i in V
M * x[i] >= N[i,j] for all i, j in V
In other words: x[i] cannot equal 1 if there are no edges coming out of node i, and x[i] must equal 1 if there are any edges coming out of node i.
(Here, N[i,j] is 1 if we go from i to j, and M is a sufficiently large number, perhaps equal to the maximum number of times you can traverse one edge.)
Here is the subtour-elimination constraint, defined for all subsets S of V such that S includes node 1, and for all nodes i in V \ S:
sum {j in S} (N[i,j] + N[j,i]) >= 2 * x[i]
In other words, if we visit node i, which is not in S, then there must be at least two edges into or out of S. (A subtour would violate this constraint for S equal to the nodes that are on the subtour that contains 1.)
We also need a constraint requiring node 1 to be on the tour:
x[1] = 1
I might be playing a little fast and loose with the directional indices, i.e., I'm not sure if your model sets N[i,j] = N[j,i] or something like that, but hopefully the idea is clear enough and you can modify my approach as necessary.
Prolog ways to compare variables
I was trying to implement some graph algorithms in Prolog. I came up with an idea to use unification to build a tree from the graph structure: The graph would be defined as follows: A list of Vertex-Variable pairs where Vertex is a constant representing the vertex and Variable is a corresponding variable, that would be used as a "reference" to the vertex. e.g.: [a-A, b-B, c-C, d-D] A list of VertexVar-NeighboursList pairs, where the VertexVar and the individual neighbours in the NeighboursList are the "reference variables". e.g.: [A-[B, C, D], B-[A, C], C-[A, B], D-[A]] meaning b, c, d are neighbours of a etc. Then before some graph algorithm (like searching for components, or simple DFS/BFS etc.) that could use some kind of tree built from the original graph, one could use some predicate like unify_neighbours that unifies the VertexVar-NeighbourList pairs as VertexVar = NeighboursList. After that, the vertex variables may be interpreted as lists of its neighbours, where each neighbour is again a list of its neighbours. So this would result in a good performance when traversing the graph, as there is no need in linear search for some vertex and its neighbours for every vertex in the graph. But my problem is: How to compare those vertex variables? (To check if they're the same.) I tried to use A == B, but there are some conflicts. For the example above, (with the unify_neighbours predicate) Prolog interprets the graph internally as: [a-[S_1, S_2, S_3], b-S_1, c-S_2, d-S_3] where: S_1 = [[S_1, S_2, S_3], S_2] S_2 = [[S_1, S_2, S_3], S_1] S_3 = [[S_1, S_2, S_3]] The problem is with S_1 and S_2 (aka b and c) as X = [something, Y], Y = [something, X], X == Y is true. The same problem would be with vertices, that share the same neighbours. e.g. U-[A, B] and V-[A, B]. So my question is: Is there any other way to compare variables, that could help me with this? Something that compares "the variables themselves", not the content, like comparing addresses in procedural programming languages? Or would that be too procedural and break the declarative idea of Prolog? Example graph_component(Vertices, Neighbours, C) :- % Vertices and Neighbours as explained above. % C is some component found in the graph. vertices_refs(Vertices, Refs), % Refs are only the variables from the pairs. unify_neighbours(Neighbours), % As explained above. rec_(Vertices, Refs, [], C). rec_(Vertices, Refs, Found, RFound) :- % Vertices as before. % Refs is a stack of the vertex variables to search. % Found are the vertices found so far. % RFound is the resulting component found. [Ref|RRest] = Refs, vertices_pair(Vertices, Vertex-Ref), % Vertex is the corresponding Vertex for the Ref variable not(member(Vertex, Found)), % Go deep: rec_(Vertices, Ref, [Vertex|Found], DFound), list_revpush_result([Vertex|Found], DFound, Found1), % Go wide: rec_(Vertices, RRest, Found1, RFound). rec_(Vertices, Refs, Found, []) :- % End of reccursion. [Ref|_] = Refs, vertices_pair(Vertices, Vertex-Ref), member(Vertex, Found). This example doesn't really work, but it's the idea. (Also, checking whether the vertices were found is done linearly, so the performance is still not good, but it's just for demonstration.) Now the predicate, that finds the corresponding vertex for the variable is implemented as: vertices_pair([Vertex-Ref|_], Vertex-Ref). vertices_pair([_-OtherRef|Rest], Vertex-Ref) :- Ref \== OtherRef, vertices_pair(Rest, Vertex-Ref). where the \== operator is not really what I want and it creates those conflicts.
It is an intrinsic feature of Prolog that, once you have bound a variable to a term, it becomes indistinguishable from the term itself. In other words, if you bind two variables to the same term, you have two identical things, and there is no way to tell them apart. Applied to your example: once you have unified every vertex-variable with the corresponding neighbours-list, all the variables are gone: you are left simply with a nested (and most likely circular) data structure, consisting of a list of lists of lists... But as you suggest, the nested structure is an attractive idea because it gives you direct access to adjacent nodes. And although Prolog system vary somewhat in how well they support circular data structures, this need not stop you from exploiting this idea. The only problem with your design is that a node is identified purely by the (potentially deeply nested and circular) data structure that describes the sub-graph that is reachable from it. This has the consequence that two nodes that have the same descendants are indistinguishable it can be very expensive to check whether two "similar looking" sub-graphs are identical or not A simple way around that is to include a unique node identifier (such as a name or number) in your data structure. To use your example (slightly modified to make it more interesting): make_graph(Graph) :- Graph = [A,B,C,D], A = node(a, [C,D]), B = node(b, [A,C]), C = node(c, [A,B]), D = node(d, [A]). You can then use that identifier to check for matching nodes, e.g. in a depth-first traversal: dfs_visit_nodes([], Seen, Seen). dfs_visit_nodes([node(Id,Children)|Nodes], Seen1, Seen) :- ( member(Id, Seen1) -> Seen2 = Seen1 ; writeln(visiting(Id)), dfs_visit_nodes(Children, [Id|Seen1], Seen2) ), dfs_visit_nodes(Nodes, Seen2, Seen). Sample run: ?- make_graph(G), dfs_visit_nodes(G, [], Seen). visiting(a) visiting(c) visiting(b) visiting(d) G = [...] Seen = [d, b, c, a] Yes (0.00s cpu)
Thanks, #jschimpf, for the answer. It clarified a lot of things for me. I just got back to some graph problems with Prolog and thought I'd give this recursive data structure another try and came up with the following predicates to construct this data structure from a list of edges: The "manual" creation of the data structure, as proposed by #jschimpf: my_graph(Nodes) :- Vars = [A, B, C, D, E], Nodes = [ node(a, [edgeTo(1, B), edgeTo(5, D)]), node(b, [edgeTo(1, A), edgeTo(4, E), edgeTo(2, C)]), node(c, [edgeTo(2, B), edgeTo(6, F)]), node(d, [edgeTo(5, A), edgeTo(3, E)]), node(e, [edgeTo(3, D), edgeTo(4, B), edgeTo(1, F)]), node(e, [edgeTo(1, E), edgeTo(6, C)]) ], Vars = Nodes. Where edgeTo(Weight, VertexVar) represents an edge to some vertex with a weight assosiated with it. The weight is just to show that this can be customized for any additional information. node(Vertex, [edgeTo(Weight, VertexVar), ...]) represents a vertex with its neighbours. A more "user-friendly" input format: [edge(Weight, FromVertex, ToVertex), ...] With optional list of vertices: [Vertex, ...] For the example above: [edge(1, a, b), edge(5, a, d), edge(2, b, c), edge(4, b, e), edge(6, c, f), edge(3, d, e), edge(1, e, f)] This list can be converted to the recursive data structure with the following predicates: % make_directed_graph(+Edges, -Nodes) make_directed_graph(Edges, Nodes) :- vertices(Edges, Vertices), vars(Vertices, Vars), pairs(Vertices, Vars, Pairs), nodes(Pairs, Edges, Nodes), Vars = Nodes. % make_graph(+Edges, -Nodes) make_graph(Edges, Nodes) :- vertices(Edges, Vertices), vars(Vertices, Vars), pairs(Vertices, Vars, Pairs), directed(Edges, DiretedEdges), nodes(Pairs, DiretedEdges, Nodes), Vars = Nodes. % make_graph(+Edges, -Nodes) make_graph(Edges, Nodes) :- vertices(Edges, Vertices), vars(Vertices, Vars), pairs(Vertices, Vars, Pairs), directed(Edges, DiretedEdges), nodes(Pairs, DiretedEdges, Nodes), Vars = Nodes. % make_directed_graph(+Vertices, +Edges, -Nodes) make_directed_graph(Vertices, Edges, Nodes) :- vars(Vertices, Vars), pairs(Vertices, Vars, Pairs), nodes(Pairs, Edges, Nodes), Vars = Nodes. The binary versions of these predicates assume, that every vertex can be obtained from the list of edges only - There are no "edge-less" vertices in the graph. The ternary versions take an additional list of vertices for exactly these cases. make_directed_graph assumes the input edges to be directed, make_graph assumes them to be undirected, so it creates additional directed edges in the opposite direction: % directed(+UndirectedEdges, -DiretedEdges) directed([], []). directed([edge(W, A, B)|UndirectedRest], [edge(W, A, B), edge(W, B, A)|DirectedRest]) :- directed(UndirectedRest, DirectedRest). To get all the vertices from the list of edges: % vertices(+Edges, -Vertices) vertices([], []). vertices([edge(_, A, B)|EdgesRest], [A, B|VerticesRest]) :- vertices(EdgesRest, VerticesRest), \+ member(A, VerticesRest), \+ member(B, VerticesRest). vertices([edge(_, A, B)|EdgesRest], [A|VerticesRest]) :- vertices(EdgesRest, VerticesRest), \+ member(A, VerticesRest), member(B, VerticesRest). vertices([edge(_, A, B)|EdgesRest], [B|VerticesRest]) :- vertices(EdgesRest, VerticesRest), member(A, VerticesRest), \+ member(B, VerticesRest). vertices([edge(_, A, B)|EdgesRest], VerticesRest) :- vertices(EdgesRest, VerticesRest), member(A, VerticesRest), member(B, VerticesRest). To construct uninitialized variables for every vertex: % vars(+List, -Vars) vars([], []). vars([_|ListRest], [_|VarsRest]) :- vars(ListRest, VarsRest). To pair up verticies and vertex variables: % pairs(+ListA, +ListB, -Pairs) pairs([], [], []). pairs([AFirst|ARest], [BFirst|BRest], [AFirst-BFirst|PairsRest]) :- pairs(ARest, BRest, PairsRest). To construct the recursive nodes: % nodes(+Pairs, +Edges, -Nodes) nodes(Pairs, [], Nodes) :- init_nodes(Pairs, Nodes). nodes(Pairs, [EdgesFirst|EdgesRest], Nodes) :- nodes(Pairs, EdgesRest, Nodes0), insert_edge(Pairs, EdgesFirst, Nodes0, Nodes). First, a list of empty nodes for every vertex is initialized: % init_nodes(+Pairs, -EmptyNodes) init_nodes([], []). init_nodes([Vertex-_|PairsRest], [node(Vertex, [])|NodesRest]) :- init_nodes(PairsRest, NodesRest). Then the edges are inserted one by one: % insert_edge(+Pairs, +Edge, +Nodes, -ResultingNodes) insert_edge(Pairs, edge(W, A, B), [], [node(A, [edgeTo(W, BVar)])]) :- vertex_var(Pairs, B, BVar). insert_edge(Pairs, edge(W, A, B), [node(A, EdgesTo)|NodesRest], [node(A, [edgeTo(W, BVar)|EdgesTo])|NodesRest]) :- vertex_var(Pairs, B, BVar). insert_edge(Pairs, edge(W, A, B), [node(X, EdgesTo)|NodesRest], [node(X, EdgesTo)|ResultingNodes]) :- A \= X, insert_edge(Pairs, edge(W, A, B), NodesRest, ResultingNodes). To get a vertex variable for a given vertex: (This actually works in both directions.) % vertex_var(+Pairs, +Vertex, -Var) vertex_var(Pairs, Vertex, Var) :- member(Vertex-Var, Pairs). ```Prolog This, of course, brings additional time overhead, but you can do this once and then just copy this data structure every time you need to perform some graph algorithm on it and access neighbours in constant time. You can also add additional information to the `node` predicate. For example: ```Prolog node(Vertex, Neighbours, OrderingVar) Where the uninitialized variable OrderingVar can be "assigned" (initialized) in constant time with information about the vertex' position in a partial ordering of the graph, for example. So this may be used as output. (As sometimes denoted by +- in Prolog comments - an uninitialized variable as a part of an input term, that is yet to be initialized by the used predicate and provides output.)
NetworkX bipartite graph issues
Here's the set up: I have a data frame, df, with columns labeled A,B,...,K. Each entry of column A is unique and will make up one of the two sets of vertices, call it X, in a bipartite graph, G. The entries of columns B,...,K (not all unique) make up the other set of vertices, call it Y, in the bipartite graph. We draw an edge from vertex y in Y to vertex x in X if y is in the same row as x.
Using this answer from another post, I have the following code which creates a bipartite graph with vertex sets given by the entries of column A (positioned on the right) and B (positioned on the left)
G = nx.Graph()
G.add_nodes_from(df['A'], bipartite=0)
G.add_nodes_from(df['B'], bipartite=1)
G.add_weighted_edges_from(
[(row['B'], row['A'], 1) for idx, row in df.iterrows()],
weight='weight')
pos = {node:[0, i] for i,node in enumerate(df['B'])}
pos.update({node:[1, i] for i,node in enumerate(df['A'])})
nx.draw(G, pos, with_labels = True)
plt.show()
I'm seeking advice/help with a few problems:
The number of vertices is large enough so that the vertices appear very bunched up. Is there a way of spreading out the vertices in each of the two vertex sets?
As I mentioned, this code makes a bipartite graph connecting some entries of B with some entries of A (again, based on row matching). How can I do this for each of the other columns (i.e. connecting elements of C,...,K with A in the same way)? I know there is a way to union graphs together with union(G1,G2) but I imagine there's a better way to achieve this.
I'd like to create some kind of edge coloring based on the degree of vertices in Y. I imagine the coloring will be implemented using the G.degree(), but I'm not sure how that works.
Please let me know if you have any suggestions for my problems. Thanks in advance!
Greedy Algorithm Nodes
I was asked this question on an interview. Can someone give me some insight on how to do this? I was stumped
Often, greedy algorithms they are used as heuristics. An independent set in an
undirected graph G is a set of nodes I so that no edge has both endpoints
in I. In other words, if {u,v} included in set E, then either u not included in set I or v not included in set I. The maximum independent set problem is , given G, nd an independent set
of the largest possible size.
Implement a greedy algorithm for maximum independent set based on
including nodes of smallest degree.
Your greedy strategy based on nodes degree can be the following: I := resulting set V := set of unused vertices, initially all vertices while V not empty: v := vertex in V with smallest degree I.add(v) for each u adjacent to v: V.remove(u) return I The strategy is greedy, because a single decision depends only on the local situation.
The greedy algorithm selects the elements of the probably maximum independent set S step by step.
After each step the set of vertices of the graph G is partitioned in three sets:
the set S of vertices selected so far
the set A of vertices that are adjacent to the vertices of S and therefore cannot be selected for the set S in future steps
the set R of remaining vertices that are neither in S nor in A.
In the next step one of the vertices v of R can be removed from R and added to the set S. All vertices adjacent to v must be removed from R, too, and added to A (if they are not already members of A). But which v from R should the greedy algorithm select? It should choose a vertex v from R such that the next R ( := current R \ ({v} union {vertices adjacent to v}) ) is as large as possible.
We define G[R] as the subgraph of G induced by R, this is the subgraph of G with vertices R and all edges of G that have their vertices in R. Then v should be a vertex with minimal degree in G[R] but not necessarily the vertex with minimal degree in G.