$\begingroup$Possibly Eppstein's k-th shortest path algorithm could be useful to you, you'd have to calculate the complexity though. However notice that a graph can have exponentially many paths, even between two vertices, so a polynomial (in the size of the graph) time algorithm is impossible.$\endgroup$
– G. BachJan 16 '14 at 2:19

1

$\begingroup$Maybe to clarify: what is impossible in polytime is an algorithm that explicitly enumerates all paths sorted by length. What may possibly be possible is an algorithm that groups paths according to their length in sorted order and represents that grouping implicitly.$\endgroup$
– G. BachJan 16 '14 at 3:45

$\begingroup$Thank you! This does correspond to the K shortest path routing problem. However, I wondering if I have a graph that is directed and acyclic (loop free) with a relatively small outdegree for each vertex (maximum 20 maybe...) and all possible paths have the same length is it still worth implementing Eppstein's algorithm, or is it better to use Dijkstra's algorithm generalized to find K shortest paths?$\endgroup$
– TeresaJan 16 '14 at 17:21

$\begingroup$"all possible paths have the same length". how can that be? that is an unusual graph type. what is it? is it even possible except on some kind of trivial graphs? suggest you focus on describing carefully (1) the nature of the graphs and (2) the result of the algorithm... there are many standard algorithms in this area, if more than one can work, then one can just compare their performance empirically...$\endgroup$
– vznJan 16 '14 at 19:52

1

$\begingroup$If you really need only "few" shortest paths, Eppstein is probably the way to go (my remarks about real performance apply). I hope my answer sheds some light on the problem you originally asked; if there is something you want to ask about the k-shortest paths, feel free to open a new question. If there is more discussion to be had, please take it to chat.$\endgroup$
– Raphael♦Jan 17 '14 at 21:49

1 Answer
1

The goal is to find all paths from $s$ to $t$ in a directed, acyclic graph with edge costs. Let $n$ the number of nodes, $m$ the number of edges and $p$ the number of $s$-$t$-paths. Let's look at what we have.

Naive enumeration

Use any graph traversal from $s$ to find all paths.

Sort them by length.

You can interleave the steps, but you'll end up with runtime $\Omega(n + p \log p)$ if there are $n$ nodes and $p$ paths.

Note that this algorithm is easy to parallelise.

Eppstein's Algorithm [1]

This one has runtime $O(m + n \log n + p)$ (from skimming the paper, I assume the bound is sharp, i.e. $\Theta$ holds). Note that paths are not represented explicitly.

I have no idea how well this algorithm can be parallelised.

Lower bounds

First of all, $p \in \Omega(2^n)$ in the worst case even in DAGs, see for instance this class of graphs:

Note that all nodes have small out-degree and all paths have the same length.

Therefore, $p$ dominates any algorithm for this problem (in the worst case) if we can not make further assumptions.

When you go for a traversal over all paths, you clearly have runtime $\Omega(p)$.

Conclusion

Eppstein's algorithm is asymptotically optimal even in the setting you describe. However, asymptotic analysis at this level is rough and hides "extra" work that may or may not pay off in practice (since $n$ does not tend to infinity). The naive version may very well be competitive in an application, depending on $n$, $m$ and $p$, and maybe even structural features.

Another thing to keep in mind is that above figures are all worst-case but you are probably after average runtime on some specific input set².

TCS papers are unlikely to contain a rigorous analysis that helps you decide (and it's hard to do, too). Your question reads as if your goal is a real-world application, so I recommend a pragmatic approach. If the naive approach is too slow for you, try parallelising it. If that is still to slow, you can invest the time, implement Eppstein and run some tests.