jgraphtは、2つのノード間のエッジ/頂点にウェイト(コスト)を入れるという考え方をサポートしています。これは、DefaultWeightedEdgeクラスを使用して実現できます。jgraphtでコスト関数を作成する
私のグラフでは、最短経路は見つけられないが、最も安い経路は見つけられないという要件があります。最も安いパスはより長くなるかもしれません/最短パスをたどるためにホップノードが増えます。したがって、これを達成するためにDijkstraShortestPathアルゴリズムを使用することができる。
しかし、私のユースケースはちょっと複雑です。ノードに着くときに実行する必要があるアクションのコストも評価する必要があります。
たとえば、チェスボードのようなグラフがあります(8x8フィールド、各フィールドはノードです)。すべてのエッジのウェイトは1です。左下から対角線のコーナー(右上)に移動するには、コストは16です。すべてのノードを最初に右に、次にすべてのノードを上に移動できます。 違いは:ジクザクを取るときは、自分自身を移動する方向に回転させる必要があります。あなたは16回回転します。 最初にすべてを右に移動してから上に移動するときは、1回だけ回転させる必要があります(開始方向に応じて2回)。 ジクザクのパスは、Djikstraの観点からは完璧です。論理的な観点からは、最悪です。
ストーリーショート:そのパスの前のエッジ/ノードに応じて、ノードやエッジにコストをかけるにはどうすればよいですか? jgraphtのソースコードに関連するものは見つかりませんでした。 使用する方が良いアルゴリズムはありますか?
JGraphTに関する私のコメントは、私がグラフを明示的に爆発させずにこれをサポートすればもっと方向性がありました。 私はあなたのアプローチと同様のアイデアを思いついた。しかし、私はDjikstraのパフォーマンスにどのように悪影響が及ぶかはわかりません。このグラフにはすでに11,000アークがあります。グラフはやや静的なグリッドです。したがって、最悪の場合、4つのアークから30までの新しいアークを生成します。だから我々はおおよそ80,000アークで終わる。 アプローチ:jgraphtにはいくつかのラベリングアルゴリズムがありますか? javadocのものを除いて、サポートされているアルゴリズムの概要が見つかりませんでした –
私のアドバイスは、試してみることです。アプリケーションに「十分に速い」ものを最適化しないでください。いくつかの最短経路計算を実行する必要がある場合は、Dijkstraで十分です。代わりに、許容可能なヒューリスティックを使用するA *検索を使用することもできます。あなたのデータが特定の構造を持っているなら、それはもっと速くなるかもしれません。チェックボードの例は、A *によって自明に解決されます。最短パス計算がたくさん必要で、グラフが変わらない場合は、FloydWarshallShortestPathsを使用して最短パスを一括して計算することを検討してください。 –
JGraphTには現在、ラベリングアルゴリズムがありません。そのような実装は、通常はアプリケーション固有のものです。しかし、ラベリングアルゴリズムを実装することは難しくありません。 Ahuja、Magnanti、OrlinによるNetwork Flows:Theory、Algorithms and Applicationsの本を読んで、ラベル設定アルゴリズムの詳細な説明をご覧ください。 。 –