どのk-best最短パスアルゴリズムを考慮する必要がありますか?


13

グラフ検索の最適化問題を解決しています。有向グラフを介して、k個の最適な非循環最短経路を見つける必要があります。

正確で近似的なk-bestアルゴリズムが多数あることは知っていますが、最近の研究のほとんどは、非常に大きく、非常にまばらに接続されたグラフ(道路のルーティングや方向など)を対象としているようです。

私の問題の側面を区別する:

  • グラフは約160の頂点で構成されています。

  • グラフはほぼ完全に接続されています(双方向であるため、〜160 ^ 2〜= 25kエッジ)

  • kは非常に小さい(おそらく10未満)

  • 最大パス長はおそらく制限され、同様に非常に小さくなります(例:3-5エッジ)

  • 上記で「非周期的」と言いましたが、繰り返しますが、ソリューションにはサイクルを含めることはできません。これは1-best最短パスの問題ではありませんが、k-bestの問題になります-たとえば、道路のルーティングを検討すると-AからBへの2番目の最短パスは1-bestと同じで、どこかのブロックの周りの簡単な旅行。それは数学的に最適かもしれませんが、あまり有用な解決策ではありません。;-)

  • 計算ごとに、エッジをその場で再重み付けする必要がある場合があります。エッジコストはいくつかの要因の加重合計で構成され、最終要件(取得する場合はいつでも)により、ユーザーはそれらの加重要因の独自の優先順位を指定して、エッジの重みを変更できます。これは比較的小さなグラフであるため(数百KBで表すことができるはずです)、メモリ内でグラフを複製し、再重み付けを適用してから、複製されたグラフで検索を実行するのが妥当です。しかし、その場で重みを計算しながら検索を実行するより効果的な方法があれば、興味があります。

Santos(K最短パスアルゴリズム)、Eppstein 1997(k最短パスの検索)などで説明されているアルゴリズムを探しています。Yenのアルゴリズムは、主に既存のJava 実装のために興味深いものです。私は研究論文を読むことを恐れていませんが、私の問題の詳細を捨てて、読書時間を節約するための指針を求めることは価値があると思いました。

また、Java実装へのポインターがある場合は、さらに良いでしょう。


+1、私は人々の提案に興味があり、これはこのサイトが作成された質問の正確なタイプのようです。
-KChaloux

あなたの非周期的条件は、スタートからゴールまでの他のパスが最初のパスでサイクルを作成することを意味しませんか?また、スタートとゴールの両方がブラインドアレーにある場合、すべてのパスでこれら2つのエッジを使用する必要があります。
user470365

たぶん私ははっきりしていなかった。非周期的制約は単一のパスにのみ適用されます。当然、AからBまでの2つの異なるパスがサイクルを形成します。
-AaronD

@AaronD:それで、最後にどちらを使いましたか?
ダニー

@arnaud:まだアルゴリズムに決着がついているかどうかはわかりません。質問がある場合は、この質問に更新を追加します。非巡回(別名「単純」)ソリューションを保証しないため、Eppsteinを削除しました。現在Yenのアルゴリズムを使用していますが、まだ詳細なプロファイリングや最適化に取り組んでいないため、別のアルゴリズムに置き換える必要がある場合があります。来週か2週間で更新します。
AaronD

回答:


2

私自身の質問に部分的に答えるには:

この質問を投稿してから、正のエッジウェイトと負のエッジウェイトを処理する必要があることを発見しました(非循環/単純/ループレスパスの制限は、最良のソリューションが定義されることを意味しますが、その制限なしに、負のグラフを通る最短パスは、コストサイクルは未定義です)。

Yenのアルゴリズム、および私が調べた他のほとんどのアルゴリズムは、一連の1-best検索に依存しています。ほとんどの場合、これらの中間検索にはダイクストラが使用されます。ダイクストラは負のエッジウェイトをサポートしていませんが、代わりにベルマンフォードを代用できます(少なくとも円では、おそらくローラーまたはエップシュタインでも)。Bellman-Fordの修正版を開発し、パスの長さ制限(エッジ内)および検索中の明示的なサイクルチェック(標準のポストサーチサイクル検出の代わり)を行いました。計算の複雑さは悪化しますが、私の要件にはまだ対処しやすいです。投稿の許可を得たら、このレスポンスを編集し、技術レポートにリンクします。


1

この質問は簡単にグーグルで検索でき、また重複していると思います:

そうは言っても、私はすでにEppsteinを使用および実装しており、それを推奨しています。とてもエレガントでした。私の記憶が正しければ、それも最適かもしれません。次の論文で非常にうまく説明されています。

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


最初に、Eppsteinの推奨に感謝します。もっと詳しく見ていきます。これは完全な複製ではなく、グーグルでの検索も簡単ではないと主張します。k-bestアルゴリズムを見つけるのは簡単ですが、それらの中から賢明に選択するのはそれほど簡単ではありません。数百万の頂点のまばらに接続されたグラフには、この問題に対して非常に異なるアルゴリズムが必要になると思います。10のベストではなく1000のベストを望むなら、kの複雑さをもっと気にかけます。また、論文を発表する際に一定の要因はそれほど重要ではありませんが、量産コードを出荷する際には確かに重要です。
AaronD

@AaronD:あなたの情報のためだけに、このアルゴリズムはどんな場合でも非常に効率的だと思います。おそらく、ヒューリスティック駆動の検索がそれに勝る特別なケースがあるかもしれませんが、一般的なケースでは、非常にうまくいくと思います。正確なパフォーマンスは、おそらく、実装方法、データ構造の効率、および問題に合わせた方法に依存します。
ダグニー

@arnaudこんにちは、エップシュタインの実装を共有することは可能ですか?私は同様の質問はここに掲載されている:math.stackexchange.com/questions/1661737/...
ティナJ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.