我应该考虑哪种k-best最短路径算法?


13

我正在解决图搜索优化问题。我需要通过有向加权图找到k个最佳非循环最短路径。

我知道有很多精确的和近似的k最佳算法,但是最近的大多数研究似乎都针对非常大,非常稀疏的关系图(例如道路路线和方向),而我的图都不是。

区分我的问题的方面:

  • 该图包含大约160个顶点。

  • 该图几乎完全连接(双向,所以〜160 ^ 2〜= 25k边)

  • k会很小(可能小于10)

  • 最大路径长度可能会有限制,并且也非常小(例如3-5条边)

  • 我在上面说了“非循环”,但只是重申一下,解决方案不得包含循环。这不是1最佳最短路径的问题,但对于k最佳路径却成为问题-例如,考虑一条道路路线-从A到B的第二最短路径可能与1最佳路径相同,在某个地方的街区附近快速旅行。从数学上讲,这可能是最佳选择,但不是非常有用的解决方案。;-)

  • 对于每个计算,我们可能需要即时重新加权边缘。边缘成本由几个因素的加权总和组成,最终要求(无论何时获得)都可以使用户指定自己对这些加权因子的优先级,从而改变边缘权重。这是一个相对较小的图(我们应该能够以几百KB表示它),因此将图克隆到内存中,应用重新加权,然后对克隆的图执行搜索可能是合理的。但是,如果有一种更有效的搜索方法,可以即时计算权重,那么我很感兴趣。

我正在研究Santos(K最短路径算法),Eppstein 1997(查找k最短路径)等中描述的算法。日元的算法很受关注,这主要是因为现有的Java 实现。我不害怕阅读研究论文,但是我认为值得抛开我的问题的细节,并要求提供指针以节省一些阅读时间。

而且,如果您有指向Java实现的指针,那就更好了。


+1,因为我对人们的建议很感兴趣,这似乎是该网站提出的确切问题类型。
KChaloux

您的非循环条件是否意味着从起点到目标的任何其他路径都会与第一个路径产生循环?如果起点和终点都在盲区,则每条路径都必须使用这两个边缘。
user470365 2013年

也许我不清楚。非循环约束仅适用于一条路径-自然,从A到B的任何两条不同的路径都会形成一个循环。
AaronD

@AaronD:那么,您到底使用了哪一个?
dagnelies 2013年

@arnaud:我不确定我是否已经确定要使用一种算法;如果有的话,我将为这个问题添加更新。我淘汰了Eppstein,因为它不能保证非循环(也称为“简单”)解决方案。我目前正在使用Yen的算法,但尚未进行详细的性能分析或优化,因此我可能不得不用另一种算法代替它。我会在下一两周内更新。
AaronD

Answers:


2

要部分回答我自己的问题:

自发布此问题以来,我发现我们既需要处理负的权重,也需要处理正的权重(无环/简单/无环路径的局限性意味着定义了最佳解决方案,而在没有这种限制的情况下,带有负-成本周期未定义)。

Yen的算法以及我研究的其他大多数算法都取决于一系列的1最佳搜索。大多数使用Dijkstra进行中间搜索。Dijkstra不支持负边权重,但我们可以用Bellman-Ford代替它(至少在日元中;大概在Lawler或Eppstein中)。我开发了Bellman-Ford的修改版,具有路径长度限制(在边缘)和搜索过程中的显式周期检查(代替了标准的搜索后周期检测)。计算复杂度较差,但对于我的要求仍然可以处理。如果获得许可,我将编辑此回复并链接到技术报告。


1

我想说这个问题可以很容易地用谷歌搜索,并且也是重复的:

话虽如此,我已经使用并实现了Eppstein并推荐了它。我觉得它很优雅。如果我没记错的话,它也可能是最佳选择,以下论文对此进行了很好的解释:

http://pdf.aminer.org/001/059/121/finding_the_k_shortest_paths.pdf


首先,感谢Eppstein的推荐。我会在那儿看更多。我认为这不是精确的重复,也不容易用Google搜索;找到k最佳算法很容易,但是在它们之间明智地选择却不那么容易。我希望对于一个稀疏连接的数百万个顶点的图,我想要一个与我将要解决的算法完全不同的算法。如果我想要1000最佳而不是10最佳,我会更关心k的复杂性。而且,尽管在发表论文时恒定因素并不重要,但在交付生产代码时,肯定会如此。
AaronD

@AaronD:仅供参考,无论哪种情况,我都认为该算法非常有效。也许在某些特殊情况下,启发式驱动搜索会胜过它,但是对于一般情况,我认为它做得很好。确切的性能可能更多地取决于实现它的方式,数据结构的效率以及针对问题的量身定制。
dagnelies 2013年

@arnaud嗨,您可以分享eppstein的实现吗?我有一个类似的问题张贴在这里:math.stackexchange.com/questions/1661737/...
蒂娜Ĵ
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.