Develop Reference

How do I cover all the edges of a graph with the minimum amount of nodes?

I am stuck with a NP problem for a few days, and I´m looking at new ways to look at the problem.
The city has 360 security cameras that need to be placed in all of the street intersections of a city. The idea is to look for the minimum amount of cameras that need to be placed in order to have all the streets covered .
The cameras can only cover one block unfortunately.
I am looking at each intersection as graph nodes while the streets are the edges, and initially I thought it was some kind of Chinese postman problem but that algorithm works mainly if you want to travel from one starting node and cover all the edges and return to the initial node.
So how would you cover all the streets with the minimum amount of cameras?
Any kind of enlightenment will be greatly appreciated.

Covering all edges in a graph by choosing a minimum number of vertices is the (Minimum) Vertex Cover problem. It's an NP-complete problem, so the best known algorithms for solving general instances take exponential time. (Like all NP-complete problems, it's also in NP, but this is not a helpful description here as many simple problems are too.)
However, some subclasses of graphs can be solved much more quickly. Bipartite graphs is one such class, and a grid graph (or subgraph of such) is bipartite, so you're in luck. For grid graphs, the vertices with even coordinate sum (the black dots in your diagram) constitute one of the parts in the partition, and the vertices with odd coordinate sum constitute the other: notice that there are no edges between vertices within the same part. A minimum vertex cover can be found by first finding a maximum cardinality bipartite matching, for example in O(|E|*sqrt(|V|)) time using the Hopcroft-Karp algorithm, and then applying this algorithm.

This algorithm is fast and simple to implement. It gives a good, though not always optimal, answer.
Copy graph to working copy
Select arbitrary link connecting nodes u, v
Add u and v to cover set
Remove all links from u
Remove all links from v
Repeat until no links left in working copy
Remove from cover set any leaf nodes ( nodes with just one link )
The PathFinder cams option is a C++ implementation of this algoritm using C++ and the boost graph library.
This input
l 0 1 1
l 0 2 1
l 1 2 1
l 2 3 1
l 2 4 1
l 2 5 1
gives
C++ code:
// store indices of nodes that cover links
std::set< int > setCover;
// working copy on input graph
auto work = myGraph;
graph_traits<graph_t>::out_edge_iterator ei, ei_end;
// loop until all links are covered
while (num_edges(work))
{
// select first link in working graph
auto it = edges(work).first;
int u = source(*it, work);
int v = target(*it, work);
// add non leaf nodes on selected link to cover
if( out_degree( u, myGraph ) > 1 )
setCover.insert( u );
if( out_degree( v, myGraph ) > 1 )
setCover.insert( v );
// remove all links that can be seen from new cover nodes
for (boost::tie(ei, ei_end) = out_edges(u, work); ei != ei_end; ++ei)
{
remove_edge(*ei, work);
}
for (boost::tie(ei, ei_end) = out_edges(v, work); ei != ei_end; ++ei)
{
remove_edge(*ei, work);
}
}

How to calculate the shortest path for a graph with weighted vertices?

I’m trying to figure out, how to calculate the shortest path for a graph with weighted vertices. Classical algorithms like Dijkstra and Floyd–Warshall normally work with weighted edges and I'm not seeing a way how to apply them to my case (weighted vertices):
One of the ideas I had was to convert the graph to the more classical view with weighted edges. This is what I received:
Here we have mono and bi-directional weighted edges, but I'm still not sure which algorithm would handle this in order to find the shortest path.

You can certainly do this by transforming the graph. The simplest way is to transform each edge into a vertex, and connect the new vertexes together with edges that have the same cost as the vertex that used to join them.
But you don't really need to bother with any of that...
Dijkstra's algorithm is very easy to adapt to vertex costs without using any such transformation. When you traverse an edge, instead of new_vertex_cost = old_vertex_cost + edge_weight, you just do new_vertex_cost = old_vertex_cost + new_vertex_weight.

You can reduce the problem to the classical shortest path problem and use Dijkstra, Bellman-Ford, or Floyd-Warshal as it suits the purpose. For the sake of simplicity, in what follows, I assume all weights are non-negative. I consider such an assumption reasonable since the question mentions using Dijkstra's algorithm to solve the problem. In the end, this assumption can be removed with care.
Consider most general form of the problem: Assume G = <V, E> is a directed weighted graph with weights on both edges and vertices. Construct a graph H = <V', E'>, with weights only on edges, as follows: For any node v in G, create two nodes v_in and v_out in H; add an edge (v_in -> v_out) with weight equal to the weight of node v in G. Also, for any edge (u -> w) in G, add an edge (u_out -> w_in) in H (new edge carries the same weight as the original edge).
To summarize, for any vertex in the original graph add two vertices in
H, one dedicated to ingoing edges, and the other dedicated to the
outgoing edges (also, connect the new correlated nodes in H based on
the weight of their corresponding vertex in G).
Now, you have a directed weighted graph H with no weight on vertices, but only on edges. It is easy to prove that the shortest path between (s_in, t_out) in H is the same as the shortest path between (s,t) in the original graph G.
The proof is based on the fact that any such path goes through the
edge (v_in, v_out) in H if and only if the corresponding path in
G goes through node v.
As far as the analysis goes, we have |V'| = 2|V|, and |E'| = |E| + |V|. So the reduction does not affect the asymptotic behavior of the employed algorithm for finding shortest paths.

Algorithm for minimal cost + maximum matching in a general graph

I've got a dataset consisting of nodes and edges.
The nodes respresent people and the edges represent their relations, which each has a cost that's been calculated using euclidean distance.
Now I wish to match these nodes together through their respective edges, where there is only one constraint:
Any node can only be matched with a single other node.
Now from this we know that I'm working in a general graph, where every node could theoretically be matched with any node in the dataset, as long as there is an edge between them.
What I wish to do, is find the solution with the maximum matches and the overall minimum cost.
Node A
Node B
Node C
Node D
- Edge 1:
Start: End Cost
Node A Node B 0.5
- Edge 2:
Start: End Cost
Node B Node C 1
- Edge 3:
Start: End Cost
Node C Node D 0.5
- Edge 2:
Start: End Cost
Node D Node A 1
The solution to this problem, would be the following:
Assign Edge 1 and Edge 3, as that is the maximum amount of matches ( in this case, there's obviously only 2 solutions, but there could be tons of branching edges to other nodes)
Edge 1 and Edge 3 is assigned, because it's the solution with maximum amount of matches and the minimum overall cost (1)
I've looked into quite a few algorithms including Hungarian, Blossom, Minimal-cost flow, but I'm uncertain which is the best for this case. Also there seems so be an awful lot of material to solving these kinds of problems in bipartial graph's, which isn't really the case in this matter.
So I ask you:
Which algorithm would be the best in this scenario to return the (a) maximum amount of matches and (b) with the lowest overall cost.
Do you know of any good material (maybe some easy-to-understand pseudocode), for your recomended algorithm? I'm not the strongest in mathematical notation.

For (a), the most suitable algorithm (there are theoretically faster ones, but they're more difficult to understand) would be Edmonds' Blossom algorithm. Unfortunately it is quite complicated, but I'll try to explain the basis as best I can.
The basic idea is to take a matching, and continually improve it (increase the number of matched nodes) by making some local changes. The key concept is an alternating path: a path from an unmatched node to another unmatched node, with the property that the edges alternate between being in the matching, and being outside it.
If you have an alternating path, then you can increase the size of the matching by one by flipping the state (whether or not they are in the matching) of the edges in the alternating path.
If there exists an alternating path, then the matching is not maximum (since the path gives you a way to increase the size of the matching) and conversely, you can show that if there is no alternating path, then the matching is maximum. So, to find a maximum matching, all you need to be able to do is find an alternating path.
In bipartite graphs, this is very easy to do (it can be done with DFS). In general graphs this is more complicated, and this is were Edmonds' Blossom algorithm comes in. Roughly speaking:
Build a new graph, where there is an edge between two vertices if you can get from u to v by first traversing an edge that is in the matching, and then traversing and edge that isn't.
In this graph, try to find a path from an unmatched vertex to a matched vertex that has an unmatched neighbor (that is, a neighbor in the original graph).
Each edge in the path you find corresponds to two edges of the original graph (namely an edge in the matching and one not in the matching), so the path translates to an alternating walk in the new graph, but this is not necessarily an alternating path (the distinction between path and walk is that a path only uses each vertex once, but a walk can use each vertex multiple times).
If the walk is a path, you have an alternating path and are done.
If not, then the walk uses some vertex more than once. You can remove the part of the walk between the two visits to this vertex, and you obtain a new graph (with part of the vertices removed). In this new graph you have to do the whole search again, and if you find an alternating path in the new graph you can "lift" it to an alternating path for the original graph.
Going into the details of this (crucial) last step would be a bit too much for a stackoverflow answer, but you can find more details on Wikipedia and perhaps having this high-level overview helps you understand the more mathematical articles.
Implementing this from scratch will be quite challenging.
For the weighted version (with the Euclidean distance), there is an even more complicated variant of Edmonds' Algorithm that can handle weights. Kolmogorov offers a C++ implementation and accompanying paper. This can also be used for the unweighted case, so using this implementation might be a good idea (even if it is not in java, there should be some way to interface with it).
Since your weights are based on Euclidean distances there might be a specialized algorithm for that case, but the more general version I mentioned above would also work and and implementation is available for it.

How to generate random graphs?

I want to be able to generate random, undirected, and connected graphs in Java. In addition, I want to be able to control the maximum number of vertices in the graph. I am not sure what would be the best way to approach this problem, but here are a few I can think of:
(1) Generate a number between 0 and n and let that be the number of vertices. Then, somehow randomly link vertices together (maybe generate a random number per vertex and let that be the number of edges coming out of said vertex). Traverse the graph starting from an arbitrary vertex (say with Breadth-First-Search) and let our random graph G be all the visited nodes (this way, we make sure that G is connected).
(2) Generate a random square matrix (of 0's and 1's) with side length between 0 and n (somehow). This would be the adjacency matrix for our graph (the diagonal of the matrix should then either be all 1's or all 0's). Make a data structure from the graph and traverse the graph from any node to get a connected list of nodes and call that the graph G.
Any other way to generate a sufficiently random graph is welcomed. Note: I do not need a purely random graph, i.e., the graph you generate doesn't have to have any special mathematical properties (like uniformity of some sort). I simply need lots and lots of graphs for testing purposes of something else.
Here is the Java Node class I am using:
public class Node<T> {
T data;
ArrayList<Node> children= new ArrayList<Node>();
...}
Here is the Graph class I am using (you can tell why I am only interested in connected graphs at the moment):
public class Graph {
Node mainNode;
ArrayList<Node> V= new ArrayList<Node>();
public Graph(Node node){
mainNode= node;
}
...}
As an example, this is how I make graphs for testing purposes right now:
//The following makes a "kite" graph G (with "a" as the main node).
/* a-b
|/|
c-d
*/
Node<String> a= new Node("a");
Node<String> b= new Node("b");
Node<String> c= new Node("c");
Node<String> d= new Node("d");
a.addChild(b);
a.addChild(c);
b.addChild(a);
b.addChild(c);
b.addChild(d);
c.addChild(a);
c.addChild(b);
c.addChild(d);
d.addChild(c);
d.addChild(b);
Graph G1= new Graph(a);

Whatever you want to do with your graph, I guess its density is also an important parameter. Otherwise, you'd just generate a set of small cliques (complete graphs) using random sizes, and then connect them randomly.
If I'm correct, I'd advise you to use the Erdős-Rényi model: it's simple, not far from what you originally proposed, and allows you to control the graph density (so, basically: the number of links).
Here's a short description of this model:
Define a probability value p (the higher p and the denser the graph: 0=no link, 1=fully connected graph);
Create your n nodes (as objects, as an adjacency matrix, or anything that suits you);
Each pair of nodes is connected with a (independent) probability p. So, you have to decide of the existence of a link between them using this probability p. For example, I guess you could ranbdomly draw a value q between 0 and 1 and create the link iff q < p. Then do the same thing for each possible pair of nodes in the graph.
With this model, if your p is large enough, then it's highly probable your graph is connected (cf. the Wikipedia reference for details). In any case, if you have several components, you can also force its connectedness by creating links between nodes of distinct components. First, you have to identify each component by performing breadth-first searches (one for each component). Then, you select pairs of nodes in two distinct components, create a link between them and consider both components as merged. You repeat this process until you've got a single component remaining.

The only tricky part is ensuring that the final graph is connected. To do that, you can use a disjoint set data structure. Keep track of the number of components, initially n. Repeatedly pick pairs of random vertices u and v, adding the edge (u, v) to the graph and to the disjoint set structure, and decrementing the component count when the that structure tells you u and v belonged to different components. Stop when the component count reaches 1. (Note that using an adjacency matrix simplifies managing the case where the edge (u, v) is already present in the graph: in this case, adj[u][v] will be set to 1 a second time, which as desired has no effect.)
If you find this creates graphs that are too dense (or too sparse), then you can use another random number to add edges only k% of the time when the endpoints are already part of the same component (or when they are part of different components), for some k.

The following paper proposes an algorithm that uniformly samples connected random graphs with prescribed degree sequence, with an efficient implementation. It is available in several libraries, like Networkit or igraph.
Fast generation of random connected graphs with prescribed degrees.
Fabien Viger, Matthieu Latapy
Be careful when you make simulations on random graphs: if they are not sampled uniformly, then they may have hidden properties that impact simulations; alternatively, uniformly sampled graphs may be very different from the ones your code will meet in practice...

2D waypoint pathfinding: combinations of WPs to go from curLocation to targetLocation

Please take a moment to understand my situation. If it is not comprehendable, please tell me in a comment.
I have an ArrayList of Waypoints. These waypoints are not in any order. A waypoint has the following properties:
{int type, float z, float y, float x, float rotation}
This applies to a 3 dimensional world, but since my pathfinding should not care about height (and thus treat the world as a 2 dimensional one), the y value is ignored. Rotation is not of importance for this question.
In this 2 dimensional world, the x represents the x axis and the z represents the y axis.
If x increases, the object in the world moves east. If x decreases, the object in the world moves west.
If z increases, the object in the world moves north. If z decreases, the object in the world moves south.
Thus, these "new" waypoints can be simplified to: waypoint = {float x, float y}.
Now, these waypoints represent the X-axis (x) and Y-axis (z) locations of an object. Moreover, there is a current location: curLocation = {float x, float y} and a target location: tarLocation = {float x, float y}.
This is what I want to get:
All combinations of waypoints (aka: paths or routes) that will lead from curLocation to tarLocation under the following strict conditions:
The distance inbetween each waypoint may not be bigger than (float) maxInbetweenDistance. This includes the initial distance from curLocation to the first waypoint and the distance from the last waypoint to tarLocation. If no such combination of waypoints is possible, null should be returned.
When multiple waypoints are found within maxInbetweenDistance from a waypoint that lead towards the target waypoint, the closest waypoint should be chosen (even better would be if an alternative waypoint that is slightly further away would result in a new path with a longer distance that is also returned).
The order of returned waypoint combinations (paths) should be from shortest route (minimum distance) to longest route (maximum distance)
Finally, please consider these points:
This is the only thing I need to do AI/pathfinding wise, which is why I do not wish to use a full blown pathfinding or AI framework. I believe one function should be able to handle the above.
If returning all possible combinations of waypoints causes too much overhead, it'd also be fine if one can specify a maximum amount of combinations (but still ordered from closest to furthest). Eg. the 5 closest paths.
How would I achieve this? Any feedback is appreciated.

I think your solution is to start with Dijkstra's Algorithm to find the shortest path first. You can consider your waypoints to be a connected graph where nodes are connected if they are close enough in the xy plane then apply Dijkstra (there are many example code listings online).
Now you have the shortest path through your graph from start to finish, which will be composed of N edges of the graph.
You would next need to create N new graphs, each just like the first, but with one segment of your shortest route un-connected. Find the shortest routes from start to finish on these modified graphs. Now you have N+1 routes which you can sort by length.
Repeat this until you have found enough paths for your needs, or there are no unranked paths left.
I haven't found a name for this technique, but it is described as a modification to Dijkstra here.

If your waypoints possess connectivity, you should take a look at Dijkstra's shortest path algorithm. The first couple of google hits even lists an implementation in Java. (I can't tell if connectivity is known from the post, but it does contain the "graph-algorithm" tag, so I'll assume so). As the name suggests, this method give you a shortest path between the two nodes.
Your constraints are challenging, as is the need for all possible combinations of paths under those constraints. Again - assuming connectivity exists - your node adjacency matrix can enforce your maxInbetweenDistance rule. Likewise, you can use this matrix in obtaining the "next best" solutions. Once the optimal path is known, you can mark that path (or elements of it) as unavailable, then re-run Dijkstra's algorithm. By repeating this process, you can obtain a set of increasingly sub-optimal paths.
As a matter of convention: in most computational geometry problems, Z is the height, and the horizontal plane is formed by the XY axes.

Well the easiest to implement would probably be creating an ArrayList of paths, which would be in turn an ArrayList of waypoints, that contains ALL possible paths, then using a recursive function to return whether each path is Valid or not given the starting and finishing point values, and the max distance, and if a path is not valid remove it from the list. The next step would be going through each of the paths that is left and ordering them from shortest total distance to shortest. This would be the brute force method of getting what you want, so the least efficient one possible. When I get home tonight I will repost if some one already hasn't with a more efficient method for doing this in java.
Edit: if the brute force method is too much, the list of waypoints will have to be sorted some how, the best way is probably to sort them initially based on distance from the starting point.