1

Diskjstra の代替として意図された BFS ベースのパス検索アルゴリズムを思いつきました (正直なところ、過去に他の人が思いついたのではないかと思いますが、オンラインのどこにも言及されていません)。実行時間を把握しようとしていますが、友人と議論していて、決定的な答えを出すことができませんでした. Go でのアルゴリズムの説明と実装へのリンクは次のとおりです: https://github.com/joshlf13/bfspath

実行時間は e + e^2 + e^4 + ... + e^2d であるという印象を受けています。ここで、e は頂点あたりのエッジの平均数、d は最終的な最短パスの距離です (O (e^2d))。問題は、これがアルゴリズムの結果に依存していることです。私の友人が指摘しているように、実行時間の考慮に含めるべきではありません。

私の推論は次のとおりです。BFS の各パスは、e の倍数と見なされる頂点の数を増やします。さらに、頂点が考慮されるたびに、それは e 操作です。したがって、各パスは v (パス内の頂点の数) x e です。v が 1 の場合、e の場合は e^2 など、v*e は e + e^2 + e^4 などです。

別のアプローチは、考慮されるエッジの数に関して実行時間を考慮することです。長さ N のエッジには、N 回の操作が必要です。したがって、エッジが E 個あり、平均エッジ長が N であるグラフの場合、それは O(N*E) です。ただし、これはアルゴリズムの操作中に考慮されるグラフの部分にのみ適用され、そのサブセットのサイズは、開始点と終了点の間の距離に比例してスケーリングされないため、O() の真の考慮が困難になります。 .

アイデア…?

4

1 に答える 1

0

したがって、アルゴリズムの最も根本的な問題は、エッジに実数値の重み/長さがある場合、正しい答えを保証できないことです。コンピューターで利用可能な最小の浮動小数点値である「単位長」を完全に準備していない限り (ヒント: これは非常に小さい)、すべてのエッジを分割することはできません。

したがって、あなたのアルゴリズムは、任意の時点で水平方向または垂直方向にのみ移動できる均一なグリッドに縮小できるグラフの正しい答えのみを返します。

ランタイムの分析に関しては、あなたの友人は完全に正しいです。「O()の真の考察」について「難しい」ことは何もありません。あなたのアルゴリズムは、複雑性理論で疑似多項式時間と呼ばれるものです。これが実際に意味することは、入力のサイズは指数関数的ですが、値は多項式であるということです。特に、O(NE + V) です。ここで、N はグラフ内のすべてのエッジの中で最大のエッジの重みです。

たとえ整数の辺の長さを保証できたとしても、グラフの疑似多面体アルゴリズムは/現実世界での使用には/遅すぎる/です。実際には均一長のグリッドでのみ使用でき、人々は/すでに/均一長のグリッドで BFS を使用しています。それは「特別なアルゴリズム」ではなく、BFS です。

于 2013-06-12T20:10:06.830 に答える