A graph with 1 connected component contains no circle and not a tree.
what type is this kind for graph?
I did a lot of googling and even look up all graph types on wikipedia,but didn't find one fit that criteria.
Related
Give an example of a graph that has the following properties. (Note that you need to give a single graph as the answer.)
The graph does not contain a triangle (that is, a clique of 3 vertices) as a subgraph.
Graph needs at least 4 colors for a proper vertex coloring
[If you think that such a graph is not possible, then prove that statement.]
1.Tomorrow we have a final exam, and this question may on the exam paper.
2.I think it is impossible to draw such a graph. But how to prove? Thank u very much.
A web search finds https://en.wikipedia.org/wiki/Gr%C3%B6tzsch_graph
The Grötzsch graph is a member of an infinite sequence of triangle-free graphs, each the Mycielskian of the previous graph in the sequence, starting from the null graph; this sequence of graphs was used by Mycielski (1955) to show that there exist triangle-free graphs with arbitrarily large chromatic number. Therefore, the Grötzsch graph is sometimes also called the Mycielski graph or the Mycielski–Grötzsch graph. Unlike later graphs in this sequence, the Grötzsch graph is the smallest triangle-free graph with its chromatic number (Chvátal 1974).
I am trying to understand if a planarity check algorithm (eg. LR Planarity, PC Tree, PQ Tree, etc...) can be enhanced such that some edges are allowed to cross depending on their type.
I have a graph with edges of 3 different types: A,B,C
Edges of type A cannot cross any other edges.
Edges of type B can cross edges of type C and vice versa.
I did already look at a simple LR planarity test, but could not successfully implement this feature.
Is it possible to take an existing algorithm and adjust it with these rules, or is there already an algorithm, which supports this?
Take the sub-graph containing only the type A edges and use a standard planarity testing algorithm to see if it is planar.
Note: one graph may generate multiple planar embeddings [page 60] so you may need to account for this.
Once you have a planar embedding for the type A edges then you can generate a list of faces.
A path of type B edges that connects from two vertices in the planar sub-graph generated by the type A edges can only be drawn in a planar manner (not crossing any type A edges) if the end-points of the path are both on the boundary of a single face of the embedding. Adding this to the embedding will, by the Jordan Curve theorem, bisect the face into which the embedding was performed and generate two sub-faces.
Note: again, a path may be able to bisect multiple faces so you may have multiple potential embeddings.
Continue performing embeddings of type B edges/paths which connect at both ends to the type A sub-graph and, at each step bisecting a face until you either reach a point where there is no viable face to bisect (and the graph is non-planar) or the type A and type B edges are planar.
Since type C edges can cross type B (and vice-versa) you can embed the type C edges (using the same method of face bisection) into the type A sub-graph without considering the type B edges (since they can be crossed).
While this can be done in O(N) for type A and either B or C (since that is effectively just an ordinary planar embedding), you may have to test multiple embeddings to find an orientation of the faces which works for A, B & C together and the resulting algorithm will almost certainly not be O(N).
Alternatively, if you know the constraints on the permutations of the faces when generating different embeddings then adding in some sort of constraint-based solver to reconcile the orientation of the paths in the embedding may assist.
take the subgraph with edges of typeB and type C with out applying planarity testing, then try to add edges of type A to the subgraph by applying planarity testing algorithm.
I am working on an atmospheric simulation for a video game, and a problem I have stumbled into is that I need a cheap (in processing time) way to determine if a graph of nodes in a rectangular grid (each node is connected to up to four neighbours, NSEW) would become partitioned if I removed a particular node.
I have tried searching for ways of detecting if a graph is partitioned but so far I have not found anything that suits my problem. I have not taken advanced math courses and only have basic knowledge of graph theory so it is possible that I just have not been searching with the right terms.
If possible, it would be very very desirable to avoid having to search through the whole graph.
You can find articulation points using a modified depth first search - see http://en.wikipedia.org/wiki/Biconnected_component. An articulation point of a graph is a node that, if removed, disconnects the graph. Every graph can be split up at the articulation points into biconnected components. If you are lucky, you just need to know whether a point is an articulation point. If not, perhaps splitting the graph up into a tree of biconnected components and analysing them will help.
I have searched related issues about subgraph enumeration. However, they didn't meet my requirement(*). (If I misunderstood something, please tell me.)
Is there an efficient algorithm or tools for the enumeration of all "connected, and unlabelled" subgraphs of a undirected parent graph.
In my case, the parent graph is an Internet topology so the amount of nodes could be large. And I would like to enumerate all of the connected unlabelled patterns (i.e. subgraphs) of the parent graph.
(*) I have searched Efficiently find all connected subgraphs and Subgraph enumeration but both of them were targeting on vertex-labelled induced and complete subgraphs respectively. But all I want is just the connected unlabelled subgraphs.
A topic name that might be helpful is "frequent subgraph mining", which is what it seems to be one name for this. There are various tools and algorithms in this area, although they may not do exactly what you want, of course.
As other point out in the answers to the two questions in your links, the number of subgraphs of large graphs can be very large. Assuming you actually want to list them, not just count them then it might take a long time.
Edit : OP has pointed out that the input here is ONE large graph, not a set of smaller ones, which will not work with standard graph mining
I still think the general approach can work here. The input set of graphs for mining is some subset of the subgraphs of your data graph. But that subgraph-set is what you want in the first place!
So lets say you pick a size of subgraph that you want (let's say 6 vertices) then you randomly pick starting vertices in your parent (the internet topology) and 'grow' these seeds, weeding out at each growth step those that don't match. Then repeat for different sizes of subgraph.
Of course, this is a probabilistic algorithm, but it could give you some idea.
I'd like to use the parallel MST algorithm dense_boruvka_minimum_spanning_tree from boost.
One required parameter for the interface of that algorithm is a graph which "must be a model of Vertex List Graph and Distributed Edge List Graph". I found that the only model of boost that incorporates the Distributed Edge List Graph concept is the Distributed Adjacency List. However in the section "Graph Concepts" of that model it is explicitly said that
"[...] the distributed adjacency list does not model the Vertex List Graph or Edge List Graph concepts [...]
(Emphasized by me)
At this point I am confused. I'm supposed to pass a data structure to the interface of a boost algorithm which is not provided by the framework? Did I misunderstand something?
NB: I'm pretty new in the boost world.
Boost graph provides generic algorithms around concepts, and has historically included very few models of graph concepts. People will generally have their graphs already in some existing datastructure that they can adapt.
In this light
At this point I am confused. I'm supposed to pass a data structure to the interface of a boost algorithm which is not provided by the framework?
is not even so strange.
The concept of DistributedAdjacencyList only provides DistributedVertexListGraph when you need VertexListGraph.
The key difference is highlighted under DVLG:
A Distributed Vertex List Graph is a graph whose vertices are distributed across multiple processes or address spaces. The vertices and num_vertices functions retain the same signatures as in the Vertex List Graph concept, but return only the local set (and size of the local set) of vertices.
In other words: a DVLG is really just a VLG already, just distributed.
What you will want to do is "undistribute" the DVLG using the VertexListAdaptor:
The vertex list graph adaptor adapts any model of Distributed Vertex List Graph in a Vertex List Graph. In the former type of graph, the set of vertices is distributed across the process group, so no process has access to all vertices. In the latter type of graph, however, every process has access to every vertex in the graph. This is required by some distributed algorithms, such as the implementations of Minimum spanning tree algorithms.
The solution seems to be the "VertexListAdaptor": http://www.boost.org/doc/libs/1_47_0/libs/graph_parallel/doc/html/vertex_list_adaptor.html