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


3
エレベータは、移動階の注文への最短経路を見つけるためにどのアルゴリズムを使用していますか?
エレベータをシミュレートしようとしています。いつも一度に1つの注文のみを受け取ることで非常に簡単に始め、キューの形でエレベータにメモリを追加して、床が押された順に移動するようにしました。これは明らかに最善のアプローチではありません。 そのため、現時点では、非常にシンプルで「近視眼」のロジックを使用しています。つまり、現在のフロアで自分に最も近いフロアを見つけ、次の目的地として設定し、リストにフロアがなくなるまでループします。 しかし、これは常に機能するわけではありません。たとえば、エレベーターは5階の建物の3階にあり、注文4,5,2を取得しました。最短経路は2から4になります。コードに応じて、コストが5の4-> 5-> 2が選択される可能性は同じです。 最短経路を見つけてエレベーターをより効率的にするにはどうすればよいですか?

5
「グラノーラ棒」のような構造の集合質量を見つけるアルゴリズムは?
私は惑星科学研究者であり、私が取り組んでいるプロジェクトの1つは、土星の環のN体シミュレーションです。この特定の研究の目標は、粒子が自身の自己重力の下で凝集するのを観察し、凝集塊の総質量とセル内のすべての粒子の平均速度を測定することです。これが、土星の夏至の間にカッシーニ宇宙船によって行われた観測を説明できるかどうかを解明しようとしています。以下は、任意のタイムステップがどのように見えるかのスクリーンショットです。(各粒子の直径は2 mで、シミュレーションセル自体の直径は約700 mです。) 私が使用しているコードは、すでにすべてのタイムステップで平均速度を吐き出します。私がしなければならないのは、塊の中の浮遊粒子ではなく、塊の中の粒子の質量を決定する方法を見つけ出すことです。私はすべての粒子の位置、質量、サイズなどを知っていますが、例えば、粒子30,000〜40,000と102,000〜105,000が人間の目に明らかな1本の鎖を構成していることは簡単にはわかりません。 したがって、私が記述する必要があるアルゴリズムは、すべての粒子位置を通過し、どの粒子が塊に属しているかを把握し、計算するユーザー入力パラメーターを可能な限り少なくする必要があります(複製可能性と客観性のため)質量。セル上のすべてとは対照的に、「各」クランプ/ストランドに対してそれを行うことができれば素晴らしいと思いますが、実際にそれらを分離する必要はないと思います。 私が考えていた唯一のことは、あらゆる粒子間の距離を計算するN 2距離計算を行うことでした。たとえば、最も近い100個の粒子が特定の距離内にある場合、その粒子はクラスタ。しかし、それはかなりずさんなようであり、CSの人々やプログラマーがよりエレガントなソリューションを知っていることを望んでいましたか? 私のソリューションで編集: 私がやったのは、ある種の最近隣/クラスターアプローチを採用し、最初にクイックnダーティN 2実装を行うことでした。したがって、すべての粒子を取得し、他のすべての粒子までの距離を計算します。クラスター内のしきい値は、d距離内にN個の粒子があるかどうかでした(残念ながら、先験的に設定する必要がある2つのパラメーターですが、応答/コメント、私はそれらのいくつかを持っていないことで逃げるつもりはなかった)。 次に、距離を並べ替えずに、順序Nの検索を行ってd内のパーティクルのカウンターをインクリメントすることで速度を上げました。その速度は6倍になりました。ツリーコードについてはほとんど何もありません)。Iは、グリッドの設定数に(グリッドサイズ≈7ときに最良の結果をシミュレーションセルを分割D細胞と主グリッドラインアップは、1つのグリッドがで半分だけオフセットされている)のxとyの、及び他の二つがずれています1/4 x ± xおよび± y。次に、コードはパーティクルをグリッドに分割し、各パーティクルNはそのセル内の他のパーティクルまでの距離を計算するだけで済みます。 理論的には、これが実際のツリーである場合、N 2の速度ではなく次数N * log(N)を取得する必要があります。私は2つの間のどこかに行きました、そこでは50,000個の粒子のサブセットで速度が17倍になり、150,000個の粒子のセルでは速度が38倍になりました。最初の12秒、2番目の53秒、500,000粒子セルの460秒。これらは、コードがシミュレーションを1タイムステップ先に実行するのにかかる時間に匹敵する速度であるため、この時点では妥当です。ああ-そしてそれは完全にスレッド化されているので、私がそれに投げつけることができる限り多くのプロセッサーを必要とします。

3
エレベーターのアルゴリズムと実装[終了]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 (実際の)エレベーターの仕組みを知りたかった。しかし、これまでのところ、私は彼らが使用するアルゴリズムに関する多くの資料も、シミュレーション用のソフトウェア(もしあれば)を見つけることができませんでした。誰かが私にその参考文献を教えてもらえますか?

2
「コマンド」と「複合」を組み合わせて時間遅延をシミュレートするにはどうすればよいですか?
学習課題(私は学校にいない-何か新しいことを学ぼうとしている老人)として、伝播遅延を組み込んだ論理ゲートシミュレーションを記述しようとしています。また、ユーザーはゲートをグループ化して、より高レベルのオブジェクトを作成できる必要があります。 問題にデザインパターンを適用したいのですが、苦労しています。 Head First Design Patternsを読んでいますが、コマンドパターンは、遅延のある回路を通る電気パルスをシミュレートするのに適した方法であることがわかりました。また、複合パターンはネストされたユニットをシミュレートするための優れた方法であることがわかります。2つを混ぜる方法がわかりません。 つまり、ゲートをループすると、ゲート「x」が発火するはずです。15ナノ秒の遅延があるので、現在のゲーム時間から15 nsのタイムスタンプでコマンドを作成します。ディスパッチャーはどこですか?ダイナーの例では、コマンドが「注文」であるため、ウェイトレスとコックはそれぞれコマンドをディスパッチし、遅延を導入するオプションがあります。「複合」ゲートがある場合、独自のディスパッチャーも持っていますか?キューを管理するためにシングルトンを使用する必要がありますか? 私は見つけたものを読みましたが、それでも正しい方向へのプッシュが必要です。 /programming/2015549/using-command-design-pattern /programming/12016314/client-server-command-design-pattern-with-variable-delays /programming/10560892/composite-of-commands-design-pattern /programming/8874705/how-can-i-calculate-propagation-delay-through-series-of-combinational-circuits-u

2
(車両)トラフィックネットワーク内で最短経路を見つけるためのより良いアプローチはありますか?
プログラマの皆さん、 車両の通行をシミュレートするソフトウェアを開発しています。「割り当て」と呼ばれるプロセスの一部は、ルートへの車両の割り当てに関係しており、ある種の最短経路探索アルゴリズムを使用する必要があります。 伝統的に、人々はダイクストラでこれを行っており、特定の科学文献は、おそらくグラフの性質のために、A *や他の代替案は大幅な改善をもたらさないことを示しているようです。 したがって、ダイクストラも使用しています。小さな問題が発生しました。交通リンク(交差点間の道路のスパン)をエッジとして扱い、交差点をノードとして扱う場合、古典的な単方向グラフを取得できません。交差点に近づくと、頻繁に方向転換できるかどうかは従来のグラフでは、ノードから任意のエッジを取得できますが、 この問題は、リンクと交差のペア(「ラス」と呼ばれます)をノードとして表すことで簡単に解決できました。後続の「ラス」または選択したポイントに到達するにはリンクをたどる必要があるため、エッジがこのトラバーサルとして定義され、典型的なグラフが得られます。 次に、結果は単純なテーブルN x Nに格納されます。ここで、Nは「ラス」の数です。 これは(避けられない?)欠点です。シミュレーションの一般的なネットワークに2000の交差点がある場合、約6000リンク、つまりN = 3Vになります。明らかに、交差(V)で数えると、O(log(3V)*(3V + E))になります。 3(または9)は一定の要素であると主張するかもしれませんが、実際の観点からは、処理速度がかなり遅くなり、ストレージスペースが3V x 3Vに増加します。 これを再構成してパフォーマンスを向上させる方法を誰かが知っていますか?必ずしも別のアルゴリズムである必要はありません。おそらく、他の方法でグラフに合うようにデータ構造を再形成しますか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.