私のアプローチコアはエンジンです。 - ページ 145 1...138139140141142143144145146147148149150151152...184 新しいコメント Реter Konow 2019.01.13 14:59 #1441 Oleg Papkov:私は、エンジンへのフローとエンジンからのフローのすべてに、何らかのフロー特性、マジックナンバーのようなもの、テスターと連動するフロー特性（それは必ずユニークである）があるはずだと仮定しています。エンジンは現在設定されているフローに反応し、Expert Advisors、Indicatorsは情報ストリームの属性（疑似マジックナンバー）に反応する。 現在、テスターではすべて正常に動作しており、私は別のウィンドウからテスターのExpert Advisorを制御しています。シミュレーターモードになっています。現在、EAとエンジンの間のメッセージは、特定のメイジやEAの名前に縛られることはありません。エンジンがリソースに情報を書き込めば、通信設定されているExpert Advisorはそれを読み取ることができるということです。通信の流れを分けるために、各EAはメッセージのヘッダーに特別なラベルを定義する必要がある。そして、説明書を読んで従うか、無視するかのどちらかです。テスターにはExpert Advisorのラベルが別にあるはずです。 しかし、ここではエンジンのユニバーサルGUIが必要であり、そこから通信の設定や切り替えを行うことができるのです。また、Expert Advisorに関する情報を受け取ることができます。 だから、EAの概念を変えなければならない。正確には、バージョンアップする必要があります。 ここでつまづいたのが EAごとにカスタムGUIを用意するか、共通のGUIを用意するか、どちらかにしなければならないのです。一般的なものであれば、不変であるはずです。事前によく考えておく必要があります。各Expert Advisorは（GUIがなくても）、エンジンに提供する内部レバーを持っている必要があります。 何か考えないと...。 Oleg Papkov 2019.01.13 15:22 #1442 Реter Konow:しかし、ここで、エンジンの設定や通信の切り替えを行うための汎用的なGUIが必要になるのです。また、EAに関する情報を受け取るため。エンジンには、必要かつ十分な恒久的な設計と構成を持つ、制御の管理を扱う管理部分と、顧客のプロジェクトに従って 作られた最も多様なカスタム部分があればよいのです。 Реter Konow 2019.01.13 15:37 #1443 Oleg Papkov:単に、エンジンの中に、必要かつ十分な恒久的な設計と構成を持つ管理部分があり、その管理部分を処理し、お客様のプロジェクトに従って作られた多種多様なカスタマイズ部分があればいいのです。この事務的な部分は理解できない。それはどういったものなのでしょうか？ 1つのExpert Advisorでエンジンが動くのであれば、それはそれでいいのです。しかも、それが数種類のものと連動していれば、また別の話です。 まだ、概念的な枠組みがない...。 Oleg Papkov 2019.01.13 16:35 #1444 Реter Konow:これが不明確なのは、事務的な部分です。どうあるべきか？ 1つのEAでエンジンが動くなら、それはそれでいいんです。数種類で動くなら、それもありですね。 これまでは、概念的な枠組みが乏しく...こんな風に言ってみよう。 また、Expert AdvisorやIndicatorの開始設定では、同じフィールド「Object 1」などを指定します。 Реter Konow 2019.01.13 18:17 #1445 Oleg Papkov:このようなものがあったとします。 また、EAやインジケーターの起動設定には、同じフィールド「オブジェクト1」などを設定します。どうなんでしょうね。このボタンで接続を切り替えろということでしょうか？しかし、この場合、すべてのExpert Advisorは、異なるペアで実行されている1つのEAのコピーである必要があります。 また、Expert Advisorが異なる場合はどうでしょうか。 Реter Konow 2019.01.13 20:51 #1446 Oleg Papkov:こんな風に言ってみよう。 また、EAやインジケーターの起動設定には、同じフィールド「オブジェクト1」などを設定します。まず、私が実装します。1つのEAを異なるペアで使用した場合。そして、様々なEAとの付き合い方を考えていきます。 Реter Konow 2019.01.13 20:58 #1447 ちなみに、コンストラクタを使った作業の良いデモを紹介します。ダイナミックに、言葉を使わずに、音楽に合わせて。:) ビジュアルスタジオの作成 https://www.mql5.com/ru/blogs/post/712102 Oleg Papkov 2019.01.14 01:38 #1448 Реter Konow:ちなみに、コンストラクタを使った作業の良いデモを紹介します。ダイナミックに、言葉を使わずに、音楽に合わせて。:) ビジュアルスタジオ オリジナルです。 Oleg Papkov 2019.01.14 01:45 #1449 Oleg Papkov:こんな風に言ってみよう。 また、EAやインジケーターの起動設定には、同じフィールド「オブジェクト1」などを設定します。これらは、コントロールに接続されていることを示すマークです。そして、制御される対象は1つだけです。だから、どこかに大きく表示されるトグルスイッチがあるのです。 Реter Konow 2019.01.14 08:52 #1450 Oleg Papkov:これらは、コントロールに接続されていることを示すマークです。しかし、具体的に制御しているのは1つだけです。だから、どこかに大きく表示されるトグルスイッチがあるのです。各EAはパラメータカーネルの独自のコピーを持っています。共通GUIから一時的に切り離し、別のEAでエンジンと接続することも可能です。同じEAのコピーであることが重要です。 しかし、ここには私自身も理解しきれていない難しさがあります。 理屈で言うと、こんな感じの質問です。 共通のGUIを持つエンジンを1つ作り、それをすべてのEAコピーに接続できるのであれば、なぜEAコピーの各チャートにGUIを持つエンジンを追加する必要があるのでしょうか？ 実際には、技術的な問題に遭遇することもあります。 Expert Advisor のコピーは、パラメータカーネルのコピーに新しい値を書き込むことができます。片方のコピーがエンジンに接続されていない場合、カーネルはコピー側のみ変更されます。そのため、再接続時にはカーネル全体をエンジンに渡す必要があり、エンジンはすべてのウィンドウのすべての要素を必要な場所に再描画します。これは原理的に可能です。 あるいは、パラメータカーネルそのものをリソースにしてやり直す。その場合、エンジンはすべての変更を一度に取得し、エレメントを再描画するだけです。これは、決して悪いことではありません。 しかし、それは私たちに何を与えてくれるのでしょうか？ おそらく、CPUの負荷を減らし、スレッドを解放しているのでしょう。10組のEAが動いていて、それぞれのエンジンにGUIを搭載すると、トータルのCPU負荷が大きくなりすぎることがあります。なぜなら、GUIのたびに要素の再描画が必要で、それはCPUに大きな負荷を与えるからです。しかし、実際には1コマの具体的なGUIを見ることができるだけです。他は隠しています。 だから、それが正解なのでしょう。共通のエンジンを作る。 1...138139140141142143144145146147148149150151152...184 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
私は、エンジンへのフローとエンジンからのフローのすべてに、何らかのフロー特性、マジックナンバーのようなもの、テスターと連動するフロー特性（それは必ずユニークである）があるはずだと仮定しています。エンジンは現在設定されているフローに反応し、Expert Advisors、Indicatorsは情報ストリームの属性（疑似マジックナンバー）に反応する。
現在、テスターではすべて正常に動作しており、私は別のウィンドウからテスターのExpert Advisorを制御しています。シミュレーターモードになっています。
現在、EAとエンジンの間のメッセージは、特定のメイジやEAの名前に縛られることはありません。エンジンがリソースに情報を書き込めば、通信設定されているExpert Advisorはそれを読み取ることができるということです。通信の流れを分けるために、各EAはメッセージのヘッダーに特別なラベルを定義する必要がある。そして、説明書を読んで従うか、無視するかのどちらかです。テスターにはExpert Advisorのラベルが別にあるはずです。
しかし、ここではエンジンのユニバーサルGUIが必要であり、そこから通信の設定や切り替えを行うことができるのです。また、Expert Advisorに関する情報を受け取ることができます。
だから、EAの概念を変えなければならない。正確には、バージョンアップする必要があります。
ここでつまづいたのが
EAごとにカスタムGUIを用意するか、共通のGUIを用意するか、どちらかにしなければならないのです。一般的なものであれば、不変であるはずです。事前によく考えておく必要があります。各Expert Advisorは（GUIがなくても）、エンジンに提供する内部レバーを持っている必要があります。
何か考えないと...。
しかし、ここで、エンジンの設定や通信の切り替えを行うための汎用的なGUIが必要になるのです。また、EAに関する情報を受け取るため。
エンジンには、必要かつ十分な恒久的な設計と構成を持つ、制御の管理を扱う管理部分と、顧客のプロジェクトに従って 作られた最も多様なカスタム部分があればよいのです。
単に、エンジンの中に、必要かつ十分な恒久的な設計と構成を持つ管理部分があり、その管理部分を処理し、お客様のプロジェクトに従って作られた多種多様なカスタマイズ部分があればいいのです。
この事務的な部分は理解できない。それはどういったものなのでしょうか？
1つのExpert Advisorでエンジンが動くのであれば、それはそれでいいのです。しかも、それが数種類のものと連動していれば、また別の話です。
まだ、概念的な枠組みがない...。
これが不明確なのは、事務的な部分です。どうあるべきか？
1つのEAでエンジンが動くなら、それはそれでいいんです。数種類で動くなら、それもありですね。
これまでは、概念的な枠組みが乏しく...
こんな風に言ってみよう。
また、Expert AdvisorやIndicatorの開始設定では、同じフィールド「Object 1」などを指定します。
このようなものがあったとします。
また、EAやインジケーターの起動設定には、同じフィールド「オブジェクト1」などを設定します。
どうなんでしょうね。このボタンで接続を切り替えろということでしょうか？しかし、この場合、すべてのExpert Advisorは、異なるペアで実行されている1つのEAのコピーである必要があります。
また、Expert Advisorが異なる場合はどうでしょうか。
こんな風に言ってみよう。
また、EAやインジケーターの起動設定には、同じフィールド「オブジェクト1」などを設定します。
まず、私が実装します。1つのEAを異なるペアで使用した場合。そして、様々なEAとの付き合い方を考えていきます。
ちなみに、コンストラクタを使った作業の良いデモを紹介します。ダイナミックに、言葉を使わずに、音楽に合わせて。:)
ビジュアルスタジオの作成
https://www.mql5.com/ru/blogs/post/712102
ちなみに、コンストラクタを使った作業の良いデモを紹介します。ダイナミックに、言葉を使わずに、音楽に合わせて。:)
ビジュアルスタジオ
オリジナルです。
こんな風に言ってみよう。
また、EAやインジケーターの起動設定には、同じフィールド「オブジェクト1」などを設定します。
これらは、コントロールに接続されていることを示すマークです。そして、制御される対象は1つだけです。だから、どこかに大きく表示されるトグルスイッチがあるのです。
これらは、コントロールに接続されていることを示すマークです。しかし、具体的に制御しているのは1つだけです。だから、どこかに大きく表示されるトグルスイッチがあるのです。
各EAはパラメータカーネルの独自のコピーを持っています。共通GUIから一時的に切り離し、別のEAでエンジンと接続することも可能です。同じEAのコピーであることが重要です。
しかし、ここには私自身も理解しきれていない難しさがあります。
理屈で言うと、こんな感じの質問です。
共通のGUIを持つエンジンを1つ作り、それをすべてのEAコピーに接続できるのであれば、なぜEAコピーの各チャートにGUIを持つエンジンを追加する必要があるのでしょうか？
実際には、技術的な問題に遭遇することもあります。
Expert Advisor のコピーは、パラメータカーネルのコピーに新しい値を書き込むことができます。片方のコピーがエンジンに接続されていない場合、カーネルはコピー側のみ変更されます。そのため、再接続時にはカーネル全体をエンジンに渡す必要があり、エンジンはすべてのウィンドウのすべての要素を必要な場所に再描画します。これは原理的に可能です。
あるいは、パラメータカーネルそのものをリソースにしてやり直す。その場合、エンジンはすべての変更を一度に取得し、エレメントを再描画するだけです。これは、決して悪いことではありません。
しかし、それは私たちに何を与えてくれるのでしょうか？
おそらく、CPUの負荷を減らし、スレッドを解放しているのでしょう。10組のEAが動いていて、それぞれのエンジンにGUIを搭載すると、トータルのCPU負荷が大きくなりすぎることがあります。なぜなら、GUIのたびに要素の再描画が必要で、それはCPUに大きな負荷を与えるからです。しかし、実際には1コマの具体的なGUIを見ることができるだけです。他は隠しています。
だから、それが正解なのでしょう。共通のエンジンを作る。