MQL5とMQL5 Cloud Networkのユニバーサル数学計算の追加サポートのために追加すべきものは何ですか？ - ページ 7 1234567891011 新しいコメント Viktor Bokov 2012.10.30 06:53 #61 理解し、修正するのに役立つ。昨日、MetaTrader 5 Agents Managerを インストールしました。 のクラウドコンピューティングで自分のPCを利用する。MQL5クラウドネットワーク。しかし、ここで問題なのは、私のアカウント（http://www.mql5.com）にはエージェントが表示されないので、PCを使用しても課金されないということです。MT5MetaTrader 5 Agents Manager自体に口座名を入力しています。 Скачать MetaTrader 5 Strategy Tester Agent для работы в сети MQL5 Cloud Network cloud.mql5.com Подключайтесь к сети распределенных вычислений MQL5 Cloud Network и получайте дополнительный доход круглосуточно — пусть компьютер работает на вас! Rashid Umarov 2012.10.30 07:15 #62 Victuar: しかし、ここで問題なのは、私のアカウントでは、http://www.mql5.com エージェントが表示されず、PCを使用しても料金が滴下されないということです。MT5MetaTrader 5 Agents Manager 自体で、アカウント名を入力しています。 FAQを読んでみてはいかがでしょうか -https://cloud.mql5.com/ru/faq Вопросы по сети распределенных вычислений MQL5 Cloud Network cloud.mql5.com Часто задаваемые вопросы по MetaTester 5 Agents Manager Yury Reshetov 2012.10.30 19:31 #63 Renat:そこで、「ビリンググリッドの機能を向上させるためには、他にどのような機能を盛り込むべきか？おそらく、リモートで呼び出すことができるクラスのメソッドで、エージェントから値を取得するもの：リモートプロシージャコール（RPC）。こんな感じ。remote: ... double f(int x); double y(doble a, double b, int[] &c); void z(double[] &arr); void func(SomeObject *so); ... メソッドの呼び出しとともに、もちろん、メソッドを呼び出すオブジェクトの現在のフィールド値をエージェントにリモートで渡す必要があります。 メインクラスのインスタンスが何らかのメソッドを呼び出し、そのメソッドの中で他のクラスのインスタンスが生成され、クラウドにタスクを送り出すというものです。結果が返されます。例えば、チェスの手をいくつか計算するという形でタスクが作成されます。リモートで実行されるmainメソッドでは、あるクラスのオブジェクトの形で1手分のカウントで様々な組み合わせが作られ、送り出される。その結果、結果が出なかったり、計算の深さが制限を超えなければ、再び同じメソッドを呼び出す。などなど。 Renat Fatkhullin 2012.10.30 19:37 #64 her.human:端末の関与がなければ、これは良いことです。この「エージェントの一人」のデータは誰が作成するのでしょうか？スクリプトやインジケーターでできるようになるのでしょうか？どのエージェントも、他のエージェントのために生データを生成することができます。すべてのエージェントまたは選択されたエージェントにフォワードキャストで送信できます。どのエージェントも他のエージェントにデータフレームを送信することができます。エージェント間のコミュニケーションは何のためにあるのか、できれば無知な人に教えてあげてください。関連する業務で、過去の計算結果などのデータ交換が 必要な場合。クラウドである必要はないのです。ローカルエリアにエージェントの高速ネットワークを作り、その上で多くのデータ交換を伴う複雑なタスクを実行することができるのです。その結果、スーパーコンピュータがなくても強力なネットワークを構築することができるのです。 Renat Fatkhullin 2012.10.30 19:54 #65 Reshetov:おそらく、リモートで呼び出すことができ、エージェントからその値を取得するクラスメソッド。こんな感じ。 ここで、もちろん、メソッドの呼び出しとともに、このメソッドをリモートで呼び出すオブジェクトの現在のフィールド値もエージェントに渡さなければならない。 いいえ、唯一実行可能で現実的な選択肢は、データフレームを交換することです。機能のリモート実行は、まともな人なら情報環境を複製することはないので、深刻な問題ではない。フレーム ワークの一環として、機能の拡張が可能です。bool FrameSend(const long agent, // номер агента, или BROADCAST const string name, // публичное имя/метка const long id, // публичный id const double value, // значение const string filename // имя файла с данными );情報提供のために念のため。ネットワーク遅延のコストは、全体のプロセスを最適化するために、結果の明示的なバッチ処理に取り組み、データの転送頻度をできるだけ少なくする必要があります。例えば、100,000,000パスの高速（コンマ数秒以内）の数学的問題がある場合、1,000～10,000パスの部分に分けてアルゴリズム的に直ちに最適化し、結果を一括して返すバッチ処理コードを書いた方が良い。そうすれば、ネットワークに多くの時間を費やすことになる100,000,000リターンに対して、大きなアドバンテージを得ることができるのです。 我々としては、高速なタスクの場合、各エージェントに数十回から数百回に分けて出力し、レスポンスもバッチ処理することで、本気で協力しています。これにより、ネットワーク通信量を大幅に削減し、ネットワーク遅延を最小限に抑えることができます。 Yury Reshetov 2012.10.30 20:14 #66 Renat:いいえ、唯一実行可能で現実的な選択肢は、データフレームを交換することです。機能のリモート実行は、まともな人なら情報環境を複製しないので、深刻な問題ではありません。すべてのタスクがパッケージ化できるわけではありません。なぜなら、アプリケーションや非常にリソース集約的なタスクでは、結果が唯一のものであったり、まったく検出されず、無駄なタスクは途中で破棄される、つまり、見つからない結果は返されるべきでもない場合があるからです。それなら、もうひとつの方法があります。つまり、メインタスクは自分の側でタスクを生成し、それをエージェントに通知する。そしてエージェントは、タスクでリモートメソッドを呼び出し、計算し、結果が出ればリモートメソッドを呼び出して結果を返します。例えば、「フェルマー数の素因数分解を求める」という課題。もしかしたら、まったく結果が出ないかもしれないし、1つかもしれないし、いくつかかもしれない。ポイントは、これらの潜在的な約数の探索は、まず大きな数の形のオブジェクトを作成する必要があるため、非常にリソースを消費するタスクであるということです（タスクでは、情報の転送コストを削減するために、素数と仮数の2つの数だけを整数で指定することができます）。次に、素数かどうかをチェックする数字（簡易テストを実行し、90％以上の数字が素数でないことを明らかにする）。そして、単純化テストに成功したら、ループの中で、モジュロの二乗を行い、一致するものを探します。ループ終了前の条件が一致しない場合は、結果が得られず、何も返せません。この場合、エージェントはホストアプリケーションからリモートで適切なメソッドを呼び出して次のジョブを要求する必要があります。もし結果を見つけたら、別のメソッドを呼び出して同じ結果を渡さなければならない。つまり、タスクはさまざまであり、フレーム構造はすべてに適しているわけではありません。また、上記の例では、1つのタスクが2つの整数をエージェントに渡すだけなので、ネットワークの遅延コストも無視できます。 Renat Fatkhullin 2012.10.30 20:24 #67 Reshetov:アプリケーションや非常に多くのリソースを必要とするタスクでは、結果が1つだけだったり、まったく結果が出なかったりすることがあり、結論の出ないタスクは再生が進むにつれて破棄されるため、すべてのタスクをバンドルすることはできません（つまり、見つからない結果を返す必要さえ ない）。フレーム方式を使う場合は、「サーバーエージェント」に空の結果を返さないか、「パケット計算済み、データなし」フラグを返すだけでよいのです。フレームモードの仕組みはご存知ですか？EAヘッダはターミナルウィンドウの右側で起動し、リモートエージェントからの応答（データフレーム）を待ちます。つまり、サーバー部分がチャートの上に乗って、データを受け取り、何でも可視化することができるのです。読んでみて、自分で試してみてください。https://www.mql5.com/ru/code/914 ATTENTION: ビデオを再アップロードする必要があります。 Пример обработки результатов оптимизации в тестере стратегий 投票: 242012.06.11MetaQuotes Software Corp.www.mql5.com Пример визуализации результатов тестирования (динамика кривой баланса и статистические характеристики торгового советника) в процессе оптимизации. Yury Reshetov 2012.10.30 20:49 #68 Renat:フレーム方式を使う場合は、「サーバーエージェント」に空の結果を返さないようにすればよい。まあ、あくまで基本ですが。非常に計算量の多い主なタスクは再帰的である。そして、クラウドは全件検索のみを想定しているため、そのような作業には向いていないのです。多くの応用的な課題では、ブルートフォースは見通しが立たないため、使用しないことにしています。深さと幅、幅のある深さでの検索には再帰的なタスクが必要である。例えば、分子の合成。つまり、プレイ中に解答候補のツリーが構築され、各枝は計算資源を必要とする。しかし、すべての支店が有効というわけではありません。つまり、検索はどこかで止まるが、同時に他の潜在的な分岐を深さまたは幅で検索し続けるのである。完全探索は、ほとんどのアプリケーションで解を見つけるのに十分な時間がかからないため、実質的にはどこにも使われません（例：チェスの手の解析の問題）。しかし、非予想的な解の分岐を切り離す再帰的な方法は、特に分散計算において 高速性を発揮する。だからこそ、アプリケーションエンジニアをクラウドに引きつけたいのであれば、彼らがすべてを捨て、視点に関係なくすべてのバリエーションを試すと考えるのではなく、彼らのタスクに合わせてクラウドを調整する必要があります。自分たちで分散コンピューティングネットワークを作るのは簡単で、たとえギガフロップスの点では速度が遅く、コンピュータの数が少なくても、有望な方向だけを検索して、クラウドネットワークよりもずっと速く必要なソリューションを見つけることができるので、より効率的なものになるでしょう。そして、多くのプログラミング言語には、このためのツールキット、つまり既製のRPC実装が用意されている。例えば、フェルマー数の素数を探すのと同じように、サブタスクに分解することができる。メインアプリケーションはタスクを生成します。次のレイヤーでは、残りのタスクからオブジェクトを作成し、簡単なシンプルさのチェックを行います。次の層では、フェルマー数の約数が見つかるかどうかという条件を探します。見つかった数字から再びジョブが生成される。次の層では、完全な単純化チェックを行い、素数でない場合はジョブを生成する。素数であれば、その結果をメインアプリケーションに返します。次の層では、フェルマー数の非単純な約数を因数分解し、そこから前の層へのジョブを生成する。これにより、各レイヤーのエージェントがそれぞれのタスクを実行するためのコンベアが形成されます。結果が出るかどうかは不明です。重要なのは、これ以上の解答を求めるのは無理だとわかっていても、コンベアから捨てられることだ。つまり、見込みのないタスクに何千ものエージェントを積んですり潰そうとするのではなく、計算資源を大幅に節約することができるのです。 Распределенные вычисления в сети MQL5 Cloud Network cloud.mql5.com Заработать деньги, продавая мощности своего компьютера для сети распределенных вычислений MQL5 Cloud Network Renat Fatkhullin 2012.10.30 21:17 #69 Reshetov:それはあくまでも基本です。主なタスクは再帰的で、計算のためのリソースを非常に多く消費する。そして、クラウドは全件検索のみを想定しているため、そのような作業には向いていないのです。多くの応用的な課題では、ブルートフォースは見通しが立たないため、使用しないことにしています。深さと幅、幅のある深さでの検索には再帰的なタスクが必要である。例えば、分子の合成。つまり、プレイ中に解答候補のツリーが構築され、各枝は計算資源を必要とする。しかし、すべての支店が有効というわけではありません。つまり、どこかで検索が中断されるが、同時に他の潜在的な枝の深さや幅の検索が継続されるのである。1,000～10,000パスで一括計算し、重要な結果のみを返します。これは非常に有効なアルゴリズム手法です。上に具体的に書きました。完全探索は、ほとんどの応用問題では解を見つけるのに十分な時間がかからないため、ほとんど使用されません（例えば、チェスのゲームの手の解析問題など）。しかし、非予想的な解の分岐を切り離す再帰的な方法は、特に分散計算において 高速性を発揮する。だからこそ、アプリケーションエンジニアをクラウドに引きつけたいのであれば、彼らがすべてを捨て、視点に関係なくすべてのバリエーションを試すと考えるのではなく、彼らのタスクに合わせてクラウドを調整する必要があります。自分たちで分散コンピューティングネットワークを作れば、ギガフロップスの速度は低くても、コンピュータの台数は少なくても、有望な分野だけを探して、クラウドネットワークよりずっと速く必要な解決策を見つけることができるので、効率的です。そして、多くのプログラミング言語には、そのためのツールキット、つまりRPCのレディメイド実装が用意されている。例えば、フェルマー数の素数を探すのと同じように、サブタスクに分解することができる。メインアプリケーションはタスクを生成します。次のレイヤーでは、残りのタスクからオブジェクトを作成し、簡単なシンプルさのチェックを行います。次の層では、フェルマー数の約数が見つかるかどうかという条件を探します。見つかった数字から再びジョブが生成される。次の層では、完全な単純化チェックを行い、素数でない場合はジョブを生成する。素数であれば、その結果をメインアプリケーションに返します。次の層では、フェルマー数の非素数除数を因数分解し、前の層へのジョブを生成する。 データ交換とデモの例については、上記をお読みください。 すでにエージェントの作業を制御するマスタープロセスがありますね。チャート上に設置され、代理店からフレーム（大きなカスタムサイズ）を受け取ることができます。マスタープロセスでは、すでに結果としてのカスタムデータの取得、可視化、加工、保存が可能です データ交換のさらなる拡張として、マスタープロセスから任意のエージェントに追加のカスタムデータを渡すことができるようにすることを提案する。その結果、リモートエージェントに新たなカスタム条件を付与しながら、部分的に読み取ることが可能になりました。その結果、毎回条件を変えながら、好きなように読み取ることができるのです。さらに、エージェントがマスターからタスクを受け取るだけでなく、互いにデータを交換できるようになれば、さらに可能性が広がります。もちろんウィザードで行うこともできますが（データが多いと非常に遅くなります）、クラウドサーバーで直接行う方がさらに効率的で高速に行えます。 Yury Reshetov 2012.10.30 22:35 #70 Renat: また、エージェントがウィザードからタスクを受け取るだけでなく、相互にデータを転送するような拡張も考えられます。もちろん、ウィザードから行うこともできますが（データ量が多い場合は非常に時間がかかります）、クラウドサーバーから直接行う方がさらに効率的で高速に行えます。つまり、ウィザードなしで、あるエージェントから別のエージェントへ再帰的なデータ転送を行い、マスターへの結果の返送を保証することが必要なのです。例えば、コンピュータがシャットダウンされ、有効な解決策が見つからなくなったからと言って、エージェントがタスクを完了させずに作業を中断するようなことはありえないのです。例えば、チェスのゲームを分析する作業などです。ウィザードは駒を配置し、今動くべき駒の色の割り当てを生成します。つまり、1駒1割り当てです。各エージェントは、自分の駒のタスクを受け取った後、駒が動けないときは、さらなる分析のために有望でないバリエーションを捨て、新しいフォーメーションを形成し、敵の駒のタスクとして渡すのである。そして、仲間か膠着状態か探索深度を超えるまで、何度も何度も繰り返すのです。そのようなタスクが現在のクラウド実装に委ねられている場合、全探索のためのタスクパッケージを生成することしかできないのです。クラウドにはそのための十分なエージェントがありませんし、ウィザードにすべてのジョブをバッチ処理するのに十分なメモリがあるとは思えません。なぜなら、有望でないバリアントを選別する仕組みがないからです。駒の動きを解析するたびに、タスクの数は指数関数的に増えていくが、そのうちのかなりの部分は捨てられるので、完全なオーバーキルのように無意味なタスクが発生することはないのである。そして、決定木のある程度の深さや幅まで潜って初めて、見通しがつくのである。そして、このクラウドの実装における深さは1、つまりマスターからエージェントまで、そしてまた戻ってくるというものです。私が言いたいのは、こういうことです。取引には、行き止まりを切り捨てた再帰的探索の実装も必要です。単一の極値だけでなく、局所的な極値の集合（実際には多数存在する）を探索するのがよいでしょう。そして、すべての可能なバリエーションに対する探索空間は天文学的であり、すなわち、すべての分散コンピューティングネットワークから取り出したエージェントでは十分ではありません。そのために、各ステップにおいて、ある点（点座標 -EAの入力パラメータ）からある距離、ある角度値だけ離れた近傍点を列挙し、それらが現在のものと比較して結果を改善するかどうかを確認する。どれか1つでも悪くなったり、探索深度を超えるものがあれば、それらを破棄する。もし改善されたら、さらに再帰的に調べ、改善された点からさらなるタスクのセットを形成し、エージェントに配布する。極限が局所的に見つかった場合（近傍のすべての点が現在の結果を悪化させるだけ）、その結果をメインアプリケーションに返す。極限が特定されると、ウィザードに渡され、フォワードテストを使ってさらに分析される。このような課題は、バリエーションが天文学的な数にのぼるため、直接解決することはできません。また、遺伝的アルゴリズムでは、局所的な極値を探さず（近傍のグローバルな極値付近でも停止する）、極値に関係なく中間結果のみを表示する。遺伝的アルゴリズムやブルートフォースアルゴリズムの探索空間が限定的で離散的であると言うわけではありません。すなわち、マスターからエージェント、エージェントから他のエージェントへのタスクの非先行的な世代を切断し、無制限の範囲で、最大数の局所極値を探索します（ただし、必要に応じて制限を設けることができます、例えば、このアルゴリズムでの探索深さは常に制限されます）。クラウドが再帰的ジョブ転送を実装すれば、この問題は解決する。 1234567891011 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
のクラウドコンピューティングで自分のPCを利用する。
MQL5クラウドネットワーク。しかし、ここで問題なのは、私のアカウント（http://www.mql5.com）にはエージェントが表示されないので、PCを使用しても課金されないということです。MT5MetaTrader 5 Agents Manager自体に口座名を入力しています。
しかし、ここで問題なのは、私のアカウントでは、http://www.mql5.com エージェントが表示されず、PCを使用しても料金が滴下されないということです。MT5MetaTrader 5 Agents Manager 自体で、アカウント名を入力しています。
そこで、「ビリンググリッドの機能を向上させるためには、他にどのような機能を盛り込むべきか？
おそらく、リモートで呼び出すことができるクラスのメソッドで、エージェントから値を取得するもの：リモートプロシージャコール（RPC）。こんな感じ。
メソッドの呼び出しとともに、もちろん、メソッドを呼び出すオブジェクトの現在のフィールド値をエージェントにリモートで渡す必要があります。
メインクラスのインスタンスが何らかのメソッドを呼び出し、そのメソッドの中で他のクラスのインスタンスが生成され、クラウドにタスクを送り出すというものです。結果が返されます。
例えば、チェスの手をいくつか計算するという形でタスクが作成されます。リモートで実行されるmainメソッドでは、あるクラスのオブジェクトの形で1手分のカウントで様々な組み合わせが作られ、送り出される。その結果、結果が出なかったり、計算の深さが制限を超えなければ、再び同じメソッドを呼び出す。などなど。
端末の関与がなければ、これは良いことです。
この「エージェントの一人」のデータは誰が作成するのでしょうか？スクリプトやインジケーターでできるようになるのでしょうか？
どのエージェントも、他のエージェントのために生データを生成することができます。すべてのエージェントまたは選択されたエージェントにフォワードキャストで送信できます。
どのエージェントも他のエージェントにデータフレームを送信することができます。
エージェント間のコミュニケーションは何のためにあるのか、できれば無知な人に教えてあげてください。
関連する業務で、過去の計算結果などのデータ交換が 必要な場合。
クラウドである必要はないのです。ローカルエリアにエージェントの高速ネットワークを作り、その上で多くのデータ交換を伴う複雑なタスクを実行することができるのです。
その結果、スーパーコンピュータがなくても強力なネットワークを構築することができるのです。
おそらく、リモートで呼び出すことができ、エージェントからその値を取得するクラスメソッド。こんな感じ。
ここで、もちろん、メソッドの呼び出しとともに、このメソッドをリモートで呼び出すオブジェクトの現在のフィールド値もエージェントに渡さなければならない。いいえ、唯一実行可能で現実的な選択肢は、データフレームを交換することです。機能のリモート実行は、まともな人なら情報環境を複製することはないので、深刻な問題ではない。
フレーム ワークの一環として、機能の拡張が可能です。
情報提供のために念のため。
ネットワーク遅延のコストは、全体のプロセスを最適化するために、結果の明示的なバッチ処理に取り組み、データの転送頻度をできるだけ少なくする必要があります。例えば、100,000,000パスの高速（コンマ数秒以内）の数学的問題がある場合、1,000～10,000パスの部分に分けてアルゴリズム的に直ちに最適化し、結果を一括して返すバッチ処理コードを書いた方が良い。そうすれば、ネットワークに多くの時間を費やすことになる100,000,000リターンに対して、大きなアドバンテージを得ることができるのです。
我々としては、高速なタスクの場合、各エージェントに数十回から数百回に分けて出力し、レスポンスもバッチ処理することで、本気で協力しています。これにより、ネットワーク通信量を大幅に削減し、ネットワーク遅延を最小限に抑えることができます。
いいえ、唯一実行可能で現実的な選択肢は、データフレームを交換することです。機能のリモート実行は、まともな人なら情報環境を複製しないので、深刻な問題ではありません。
すべてのタスクがパッケージ化できるわけではありません。なぜなら、アプリケーションや非常にリソース集約的なタスクでは、結果が唯一のものであったり、まったく検出されず、無駄なタスクは途中で破棄される、つまり、見つからない結果は返されるべきでもない場合があるからです。
それなら、もうひとつの方法があります。つまり、メインタスクは自分の側でタスクを生成し、それをエージェントに通知する。そしてエージェントは、タスクでリモートメソッドを呼び出し、計算し、結果が出ればリモートメソッドを呼び出して結果を返します。
例えば、「フェルマー数の素因数分解を求める」という課題。もしかしたら、まったく結果が出ないかもしれないし、1つかもしれないし、いくつかかもしれない。ポイントは、これらの潜在的な約数の探索は、まず大きな数の形のオブジェクトを作成する必要があるため、非常にリソースを消費するタスクであるということです（タスクでは、情報の転送コストを削減するために、素数と仮数の2つの数だけを整数で指定することができます）。次に、素数かどうかをチェックする数字（簡易テストを実行し、90％以上の数字が素数でないことを明らかにする）。そして、単純化テストに成功したら、ループの中で、モジュロの二乗を行い、一致するものを探します。ループ終了前の条件が一致しない場合は、結果が得られず、何も返せません。この場合、エージェントはホストアプリケーションからリモートで適切なメソッドを呼び出して次のジョブを要求する必要があります。もし結果を見つけたら、別のメソッドを呼び出して同じ結果を渡さなければならない。
つまり、タスクはさまざまであり、フレーム構造はすべてに適しているわけではありません。また、上記の例では、1つのタスクが2つの整数をエージェントに渡すだけなので、ネットワークの遅延コストも無視できます。
アプリケーションや非常に多くのリソースを必要とするタスクでは、結果が1つだけだったり、まったく結果が出なかったりすることがあり、結論の出ないタスクは再生が進むにつれて破棄されるため、すべてのタスクをバンドルすることはできません（つまり、見つからない結果を返す必要さえ ない）。
フレーム方式を使う場合は、「サーバーエージェント」に空の結果を返さないか、「パケット計算済み、データなし」フラグを返すだけでよいのです。
フレームモードの仕組みはご存知ですか？EAヘッダはターミナルウィンドウの右側で起動し、リモートエージェントからの応答（データフレーム）を待ちます。つまり、サーバー部分がチャートの上に乗って、データを受け取り、何でも可視化することができるのです。
読んでみて、自分で試してみてください。https://www.mql5.com/ru/code/914
フレーム方式を使う場合は、「サーバーエージェント」に空の結果を返さないようにすればよい。
まあ、あくまで基本ですが。非常に計算量の多い主なタスクは再帰的である。そして、クラウドは全件検索のみを想定しているため、そのような作業には向いていないのです。多くの応用的な課題では、ブルートフォースは見通しが立たないため、使用しないことにしています。深さと幅、幅のある深さでの検索には再帰的なタスクが必要である。例えば、分子の合成。つまり、プレイ中に解答候補のツリーが構築され、各枝は計算資源を必要とする。しかし、すべての支店が有効というわけではありません。つまり、検索はどこかで止まるが、同時に他の潜在的な分岐を深さまたは幅で検索し続けるのである。
完全探索は、ほとんどのアプリケーションで解を見つけるのに十分な時間がかからないため、実質的にはどこにも使われません（例：チェスの手の解析の問題）。しかし、非予想的な解の分岐を切り離す再帰的な方法は、特に分散計算において 高速性を発揮する。だからこそ、アプリケーションエンジニアをクラウドに引きつけたいのであれば、彼らがすべてを捨て、視点に関係なくすべてのバリエーションを試すと考えるのではなく、彼らのタスクに合わせてクラウドを調整する必要があります。自分たちで分散コンピューティングネットワークを作るのは簡単で、たとえギガフロップスの点では速度が遅く、コンピュータの数が少なくても、有望な方向だけを検索して、クラウドネットワークよりもずっと速く必要なソリューションを見つけることができるので、より効率的なものになるでしょう。そして、多くのプログラミング言語には、このためのツールキット、つまり既製のRPC実装が用意されている。
例えば、フェルマー数の素数を探すのと同じように、サブタスクに分解することができる。メインアプリケーションはタスクを生成します。次のレイヤーでは、残りのタスクからオブジェクトを作成し、簡単なシンプルさのチェックを行います。次の層では、フェルマー数の約数が見つかるかどうかという条件を探します。見つかった数字から再びジョブが生成される。次の層では、完全な単純化チェックを行い、素数でない場合はジョブを生成する。素数であれば、その結果をメインアプリケーションに返します。次の層では、フェルマー数の非単純な約数を因数分解し、そこから前の層へのジョブを生成する。
これにより、各レイヤーのエージェントがそれぞれのタスクを実行するためのコンベアが形成されます。結果が出るかどうかは不明です。重要なのは、これ以上の解答を求めるのは無理だとわかっていても、コンベアから捨てられることだ。つまり、見込みのないタスクに何千ものエージェントを積んですり潰そうとするのではなく、計算資源を大幅に節約することができるのです。
それはあくまでも基本です。主なタスクは再帰的で、計算のためのリソースを非常に多く消費する。そして、クラウドは全件検索のみを想定しているため、そのような作業には向いていないのです。多くの応用的な課題では、ブルートフォースは見通しが立たないため、使用しないことにしています。深さと幅、幅のある深さでの検索には再帰的なタスクが必要である。例えば、分子の合成。つまり、プレイ中に解答候補のツリーが構築され、各枝は計算資源を必要とする。しかし、すべての支店が有効というわけではありません。つまり、どこかで検索が中断されるが、同時に他の潜在的な枝の深さや幅の検索が継続されるのである。
1,000～10,000パスで一括計算し、重要な結果のみを返します。これは非常に有効なアルゴリズム手法です。
上に具体的に書きました。
完全探索は、ほとんどの応用問題では解を見つけるのに十分な時間がかからないため、ほとんど使用されません（例えば、チェスのゲームの手の解析問題など）。しかし、非予想的な解の分岐を切り離す再帰的な方法は、特に分散計算において 高速性を発揮する。だからこそ、アプリケーションエンジニアをクラウドに引きつけたいのであれば、彼らがすべてを捨て、視点に関係なくすべてのバリエーションを試すと考えるのではなく、彼らのタスクに合わせてクラウドを調整する必要があります。自分たちで分散コンピューティングネットワークを作れば、ギガフロップスの速度は低くても、コンピュータの台数は少なくても、有望な分野だけを探して、クラウドネットワークよりずっと速く必要な解決策を見つけることができるので、効率的です。そして、多くのプログラミング言語には、そのためのツールキット、つまりRPCのレディメイド実装が用意されている。
例えば、フェルマー数の素数を探すのと同じように、サブタスクに分解することができる。メインアプリケーションはタスクを生成します。次のレイヤーでは、残りのタスクからオブジェクトを作成し、簡単なシンプルさのチェックを行います。次の層では、フェルマー数の約数が見つかるかどうかという条件を探します。見つかった数字から再びジョブが生成される。次の層では、完全な単純化チェックを行い、素数でない場合はジョブを生成する。素数であれば、その結果をメインアプリケーションに返します。次の層では、フェルマー数の非素数除数を因数分解し、前の層へのジョブを生成する。
データ交換とデモの例については、上記をお読みください。
データ交換のさらなる拡張として、マスタープロセスから任意のエージェントに追加のカスタムデータを渡すことができるようにすることを提案する。その結果、リモートエージェントに新たなカスタム条件を付与しながら、部分的に読み取ることが可能になりました。その結果、毎回条件を変えながら、好きなように読み取ることができるのです。
さらに、エージェントがマスターからタスクを受け取るだけでなく、互いにデータを交換できるようになれば、さらに可能性が広がります。もちろんウィザードで行うこともできますが（データが多いと非常に遅くなります）、クラウドサーバーで直接行う方がさらに効率的で高速に行えます。
Renat:
また、エージェントがウィザードからタスクを受け取るだけでなく、相互にデータを転送するような拡張も考えられます。もちろん、ウィザードから行うこともできますが（データ量が多い場合は非常に時間がかかります）、クラウドサーバーから直接行う方がさらに効率的で高速に行えます。
つまり、ウィザードなしで、あるエージェントから別のエージェントへ再帰的なデータ転送を行い、マスターへの結果の返送を保証することが必要なのです。例えば、コンピュータがシャットダウンされ、有効な解決策が見つからなくなったからと言って、エージェントがタスクを完了させずに作業を中断するようなことはありえないのです。
例えば、チェスのゲームを分析する作業などです。ウィザードは駒を配置し、今動くべき駒の色の割り当てを生成します。つまり、1駒1割り当てです。各エージェントは、自分の駒のタスクを受け取った後、駒が動けないときは、さらなる分析のために有望でないバリエーションを捨て、新しいフォーメーションを形成し、敵の駒のタスクとして渡すのである。そして、仲間か膠着状態か探索深度を超えるまで、何度も何度も繰り返すのです。
そのようなタスクが現在のクラウド実装に委ねられている場合、全探索のためのタスクパッケージを生成することしかできないのです。クラウドにはそのための十分なエージェントがありませんし、ウィザードにすべてのジョブをバッチ処理するのに十分なメモリがあるとは思えません。なぜなら、有望でないバリアントを選別する仕組みがないからです。駒の動きを解析するたびに、タスクの数は指数関数的に増えていくが、そのうちのかなりの部分は捨てられるので、完全なオーバーキルのように無意味なタスクが発生することはないのである。そして、決定木のある程度の深さや幅まで潜って初めて、見通しがつくのである。そして、このクラウドの実装における深さは1、つまりマスターからエージェントまで、そしてまた戻ってくるというものです。
私が言いたいのは、こういうことです。取引には、行き止まりを切り捨てた再帰的探索の実装も必要です。単一の極値だけでなく、局所的な極値の集合（実際には多数存在する）を探索するのがよいでしょう。そして、すべての可能なバリエーションに対する探索空間は天文学的であり、すなわち、すべての分散コンピューティングネットワークから取り出したエージェントでは十分ではありません。そのために、各ステップにおいて、ある点（点座標 -EAの入力パラメータ）からある距離、ある角度値だけ離れた近傍点を列挙し、それらが現在のものと比較して結果を改善するかどうかを確認する。どれか1つでも悪くなったり、探索深度を超えるものがあれば、それらを破棄する。もし改善されたら、さらに再帰的に調べ、改善された点からさらなるタスクのセットを形成し、エージェントに配布する。極限が局所的に見つかった場合（近傍のすべての点が現在の結果を悪化させるだけ）、その結果をメインアプリケーションに返す。極限が特定されると、ウィザードに渡され、フォワードテストを使ってさらに分析される。
このような課題は、バリエーションが天文学的な数にのぼるため、直接解決することはできません。また、遺伝的アルゴリズムでは、局所的な極値を探さず（近傍のグローバルな極値付近でも停止する）、極値に関係なく中間結果のみを表示する。遺伝的アルゴリズムやブルートフォースアルゴリズムの探索空間が限定的で離散的であると言うわけではありません。すなわち、マスターからエージェント、エージェントから他のエージェントへのタスクの非先行的な世代を切断し、無制限の範囲で、最大数の局所極値を探索します（ただし、必要に応じて制限を設けることができます、例えば、このアルゴリズムでの探索深さは常に制限されます）。クラウドが再帰的ジョブ転送を実装すれば、この問題は解決する。