タグ付けされた質問 「dijkstra」

1から5に行くとしましょう。最短ルートは1-4-3-5（合計60 km）です。 これには、ダイクストラのアルゴリズムを使用できます。 問題は、渋滞やその他の要因により、最短ルートが常に最速ルートとは限らないことです。 例えば： 1-2は頻繁に渋滞することが知られているため、避けるべきです。 4-3で突然自動車事故が発生するため、それも避ける必要があります。 等... 渋滞や事故がないため、おそらくルート1-4-5でスピードを上げることができるので、5に速く到着します。 まあそれは一般的な考え方であり、私はまだ詳細については考えていません。 この問題を解決するアルゴリズムはありますか？

17 graph  dijkstra 

私は3つを研究しており、それらからの推論を以下に述べています。それらを十分に正確に理解しているかどうかを誰かに教えてもらえますか？ありがとうございました。 ダイクストラのアルゴリズムは、単一のソースがあり、あるノードから別のノードへの最小パスを知りたい場合にのみ使用されますが、このような場合は失敗します Floyd-Warshallのアルゴリズムは、すべてのノードのいずれかがソースになる可能性がある場合に使用されるため、ソースノードから宛先ノードに到達する最短距離が必要です。これは、負のサイクルがある場合にのみ失敗します （これは最も重要なものです。つまり、これは私が最も確信していないものです:) 3.Bellman-Fordは、ソースが1つしかない場合のダイクストラのように使用されます。これは負の重みを処理でき、その動作は1つのソースを除き、Floyd-Warshallの動作と同じですか？ 見る必要がある場合、対応するアルゴリズムは次のとおりです（提供：ウィキペディア）： ベルマンフォード： procedure BellmanFord(list vertices, list edges, vertex source) // This implementation takes in a graph, represented as lists of vertices // and edges, and modifies the vertices so that their distance and // predecessor attributes store the shortest paths. // Step 1: initialize graph …

12 algorithms  graph  dijkstra 

まず、私は1974年の「科学的思考の役割について」の抜粋エズガーW.ダイクストラの論文を読みました。 私にあなたに説明しようと思います、私の好みに何がすべてのインテリジェントな思考に特徴的です。それは、自分の一貫性を保つために、自分の主題の側面を分離して詳細に研究することをいとわないことです。常に、側面の1つだけで自分を占有していることを知っています。私たちはプログラムが正しい必要があることを知っており、その観点からのみそれを学ぶことができます。また、効率的である必要があることもわかっており、いわば、別の日にその効率を調査することができます。別の気分では、プログラムが望ましいかどうか、またそうである場合、なぜプログラムが望ましいかを自問することがあります。しかし、これらのさまざまな側面に同時に取り組むことによって何も得られません-逆に！-。それは私が時々「懸念の分離」と呼んだものであり、それは完全に可能ではないにしても、私の知る限り、思考を効果的に順序付けるために利用できる唯一の手法です。これは、「ある側面に注目する」という意味です。他の側面を無視することを意味するのではなく、この側面の観点から見れば、他の側面は無関係であることを正当化するだけです。それは1つと複数のトラックを同時に気にしています。 私は、コードをモジュール化することについて、現代の懸念の分離が語られているのを見ています。しかし、上記の引用を読んで、私はこれをあなたの心を一度に1つの特定のタスクに集中させ、他の側面に焦点を合わせないものとして理解します。これは、必ずしもコードをモジュール化されたチャンクに分離する必要があることを意味するわけではありません。 つまり、1つのファイルに、ビュー、リポジトリ、コントローラー、イベント処理、ファクトリーなどの概念がすべて1つのファイルにあるというコードが目の前にあるとします。 簡単な例として、データアクセスと表示（出力）を行うコードを次に示します。 $sql = "SELECT * FROM product WHERE id = " . db_input($id); $row = db_fetch_array(db_query($sql)); <option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? ' selected="selected"' : '' ?>>Version <?=$row['ver']?></option> モダンなオブジェクト指向を使用して、リポジトリパターンを使用して独自のファイルにデータアクセスを配置し、ビューコードを独自のファイルテンプレートに入れ、それらをまとめてコントローラー（またはアクションまたはリクエストハンドラー）を介して通信することができます。ファクトリーを追加して、さまざまな依存関係を作成して接続します。そして、それらのファクトリーを定義する構成ファイルを持つことができます。確かに、それは単一ファイルのすべてから一歩離れています。 懸念の分離に関する私の質問は次のようなものです。ダイクストラの引用を読んで、おそらく彼が懸念の分離を必ずしも「コードのモジュール化（ファイルまたは独自の関数/メソッド/その他への）分離」であるとは限らないという考えを得ました。また、コードで物理的に分離されているかどうかに関係なく、他の重要であるが現時点では検討されていない側面に集中することなく、プログラムの側面に集中することを意味しました。 では、なぜ、物理的なモジュラーコードの分離と設計パターンに負担をかけているのでしょうか。コードがどのように構造化されているかに関係なく、アスペクトに専念するだけでは十分ではありませんか？ 私は最も恐ろしいスパゲッティコードを書くことについて話しているのではなく、その側面のみを検討しているので、それはおそらく負担になります。しかし、結局のところ、私が目指しているのは、物理的なコード分離を実行する理由であり、側面に精神的に集中する必要がないのに、なぜコードを個別のファイルまたはチャンク（メソッド）に分割するのか、です。 懸念の分離は、肉体的ではなく精神的な運動のままである必要がありますか？ 言い換えれば、プログラミングの精神的側面（焦点を当てる）と物理的側面（紙面上のコード）の間に断絶があるべきでしょうか？

9 design  source-code  separation-of-concerns  modularization  dijkstra