On 27/02/14 18:11, Aaron Windsor wrote:

Hi,

As described, your problem is NP-hard, which means that if you were to
find a way to solve it in polynomial time in the number of vertices in
the graph, you'd also be able to solve a lot of other hard problems that
nobody's ever been able to solve in polynomial time. For example, given
an algorithm that solves your problem, you could use that algorithm to
find Hamiltonian paths in graphs: for any graph G with n vertices, just
run the algorithm on that graph and the path (u, x_0, ..., x_{n-2}, v),
where the x_i's are vertices not appearing in G (or, say, isolated
vertices in G) and u and v are two vertices from G. If the algorithm

outputs a path, it's a path of length n-1 and thus Hamiltonian. [...]

Maybe there are some additional constraints on your actual problem or
the graphs you're dealing with that make it simpler than what you've
described above? If so, those would be good to know. If not, and you
still want to write an algorithm to do this, I'd suggest that you don't
try to do anything fancy with the BGL. Your best bet will just
enumerating through all candidate paths of the appropriate length and
checking if the candidate is an actual path in G.

Hi Aaron,

Unfortunately, you're right, it is NP-hard, however, I have some dimensions that can be relied on.

The graph G can be very huge, but each node has *at most* four outgoing edges.

The path P consists usually of ~50 nodes.

A solution is either complete, i.e., the length of a solution is equal to the length of P, or the solution is not acceptable.


The only thing I could do with BGL, then, is just to find all paths from one vertices to another, and check the length. Am I right?