Write a program that simulates a positional game, such as the connectivity game, between a given number of players.
At the beginning of the game the board contains all the edges of a complete graph with n vertices (all the pairs formed with distinct numbers from 1 to n).
Each player extracts edges successively from the board and must create with them a spanning tree of the initial complete graph.
The game ends when either a player makes a spanning tree (in this case the winner receives n points and the others 0) or when all edges have been removed from the graph (in this case each player receives a number of points equal to the number of vertices of their largest partial tree).
I have to consider the situation when the player choose random an edge and when a "smart" player should try to extend its maximal tree while not allowing others to create a spanning tree.
Related
Could someone explain in pretty simple words why the normalization of many network analysis indicies (graph theory) is n(n - 1), where n – the graph size? Why do we need to take into account (n - 1)?
Most network measures that focus on counting edges (e.g. clustering coefficient) are normalized by the total number of possible edges. Since every edge connects a pair of vertices, we need to know how many possible pairs of vertices we can make. There are n possible vertices we could choose as the source of our edge, and therefore there are n-1 possible vertices that could be the target of our edge (assuming no self-loops, and if undirected divide by 2 bc source and target are exchangeable). Hence, you frequently encounter $n(n-1)$ or $\binomal{n}{2}$.
I got a little riddle concerning graphs.
In this case it is forbidden that 3 nodes are directly connected to each other. In other words, you cannot create 3 connections between 3 nodes which would create a triangle (each corner is a node and the edges are the connections)
Prove that the biggest possible amount of connections is n² when we got 2*n nodes. Also prove that this condition is realizable for each n.
n is part of the positive natural numbers.
To answer the question in part, one can prove that the number n*n is realizable can be solved by the following proof sketch, where induction on n is used. For n=0 the graph is empty, for n=1 the graph is a straight line and for n=2 the graph is a square. For the induction step, let n be arbitrary such that there is a graph with 2n nodes which has n*n edges and is triangle free. To understand the idea of the proof, imagine the graph arranged in two rows of n nodes each. Add two nodes as a column right to this graph, creating a graph with n+2=2(n+1) nodes. Connect these nodes to each other, creating 1 new edge.
Connect the upper new node to the columns left of it, alternating between upper and lower row, starting in the upper row. This creates n edges. Likewise, connect the lower new node to the columns left of it, alternating between upper and lower row, starting in the upper row. This creates n edges. In total, the construction does not create a triangle.
In total, 2*n+1 new edges were created. In total, the graph has n*n+2*n+1=2*(n+1) edges, which is the desired amount.
I'm trying to test some models of graph partitioning (these come from the real world, where a graph slowly self-partitions). To do this, I need to be able to uniformly randomly partition this graph into contiguous components (we are given the graph is initially connected, as well). Were the contiguity criterion not required I believe this would be the problem of randomly partitioning a set, which can be combinatorially analyzed. Does anyone know of any way to randomly partition graphs into subgraphs (i.e. randomly sample one partition), or, if no such method is known, to randomly sample a set of elements? The method of randomizing the number of partitions and then randomizing membership won't work because there are different numbers of possible partitions for each partition size.
You have to differentiate edge-cut partitioning and vertex-cut partitioning, where you divide the graph along the edges or vertices. This significantly impacts your problem as the number of different vertex-cuts is much larger than the number of edge-cuts. The reason is that you exclusively assign edges to partitions in vertex-cut - as opposed to edge-cut where you assign vertices to partitions - and there are much more edges than vertices (e.g. O(n^2) edges for n vertices). Hence, the combinatorially larger vertex-cut leads to a larger number of subgraphs that have to be checked for connectivity. A naive method for randomization is to enumerate all partitionings, iteratively select one partitioning, and check connectivity of all subgraphs in the selected partitioning. Then you just take the first one. In this case, all solutions have equal probability (uniformly random).
I have come across the same problem in work I am doing. I have two solutions to randomly partition a graph into m contiguous components:
Spanning Tree Approach. Randomly choose a spanning tree of your graph (e.g. Using Wilson's algorithm which chooses uniformly amongst all spanning trees). Then randomly select m-1 edges (without replacements) and remove them from the spanning tree. This will give m components which are each connected in the original graph.
Edge contraction approach. Randomly choose an edge and contract it, renaming the (new) vertex as the union of the two previous vertices. Repeat until you have only m vertices left. Identify each vertex with the subset of (original) vertices that were contracted into it.
I don't want to find all the minimum spanning trees but I want to know how many of them are there, here is the method I considered:
Find one minimum spanning tree using prim's or kruskal's algorithm and then find the weights of all the spanning trees and increment the running counter when it is equal to the weight of minimum spanning tree.
I couldn't find any method to find the weights of all the spanning trees and also the number of spanning trees might be very large, so this method might not be suitable for the problem.
As the number of minimum spanning trees is exponential, counting them up wont be a good idea.
All the weights will be positive.
We may also assume that no weight will appear more than three times in the graph.
The number of vertices will be less than or equal to 40,000.
The number of edges will be less than or equal to 100,000.
There is only one minimum spanning tree in the graph where the weights of vertices are different. I think the best way of finding the number of minimum spanning tree must be something using this property.
EDIT:
I found a solution to this problem, but I am not sure, why it works. Can anyone please explain it.
Solution: The problem of finding the length of a minimal spanning tree is fairly well-known; two simplest algorithms for finding a minimum spanning tree are Prim's algorithm and Kruskal's algorithm. Of these two, Kruskal's algorithm processes edges in increasing order of their weights. There is an important key point of Kruskal's algorithm to consider, though: when considering a list of edges sorted by weight, edges can be greedily added into the spanning tree (as long as they do not connect two vertices that are already connected in some way).
Now consider a partially-formed spanning tree using Kruskal's algorithm. We have inserted some number of edges with lengths less than N, and now have to choose several edges of length N. The algorithm states that we must insert these edges, if possible, before any edges with length greater than N. However, we can insert these edges in any order that we want. Also note that, no matter which edges we insert, it does not change the connectivity of the graph at all. (Let us consider two possible graphs, one with an edge from vertex A to vertex B and one without. The second graph must have A and B as part of the same connected component; otherwise the edge from A to B would have been inserted at one point.)
These two facts together imply that our answer will be the product of the number of ways, using Kruskal's algorithm, to insert the edges of length K (for each possible value of K). Since there are at most three edges of any length, the different cases can be brute-forced, and the connected components can be determined after each step as they would be normally.
Looking at Prim's algorithm, it says to repeatedly add the edge with the lowest weight. What happens if there is more than one edge with the lowest weight that can be added? Possibly choosing one may yield a different tree than when choosing another.
If you use prim's algorithm, and run it for every edge as a starting edge, and also exercise all ties you encounter. Then you'll have a Forest containing all minimum spanning trees Prim's algorithm is able to find. I don't know if that equals the forest containing all possible minimum spanning trees.
This does still come down to finding all minimum spanning trees, but I can see no simple way to determine whether a different choice would yield the same tree or not.
MST and their count in a graph are well-studied. See for instance: http://www14.informatik.tu-muenchen.de/konferenzen/Jass08/courses/1/pieper/Pieper_Paper.pdf.
Consider a graph that has weights on each of its nodes instead of between two nodes. Therefore the cost of traveling to a node would be the weight of that node.
1- How can we represent this graph?
2- Is there a minimum spanning path algorithm for this type of graph (or could we modify an existing algorithm)?
For example, consider a matrix. What path, when traveling from a certain number to another, would produce a minimum sum? (Keep in mind the graph must be directed)
if one don't want to adjust existing algorithms and use edge oriented approaches, one could transform node weights to edge weights. For every incoming edge of node v, one would save the weight of v to the edge. Thats the representation.
well, with the approach of 1. this is now easy to do with well known algorithms like MST.
You could also represent the graph as wished and hold the weight at the node. The algorithm simply didn't use Weight w = edge.weight(); it would use Weight w = edge.target().weight()
simply done. no big adjustments are necessary.
if you have to use adjacency matrix, you need a second array with node weights and in adjacency matrix are just 0 - for no edge or 1 - for an edge.
hope that helped