記事"ユニバーサルEA:イベントモデルと取引ストラテジープロトタイプ(パート2)"についてのディスカッション

 

新しい記事 ユニバーサルEA:イベントモデルと取引ストラテジープロトタイプ(パート2) はパブリッシュされました:

この記事は、ユニバーサルEAのシリーズです。このパートでは、データ処理に基づいて、オリジナルのイベント・モデルについて解説し、エンジンのストラテジーの基本クラスの構造を扱います。

EAは、新しいティックを受信した場合、 OnTickOnTimer OnBookEventを 介して受信されるかどうかは関係ありません。問題は、指定されたシンボルの新しいティックがあるということです。一つのイベントハンドラで、多くのストラ テジーを用いることができます。それぞれのストラテジーは、カスタムクラスとして表現される場合、これらのクラスの複数のインスタンスは、ストラテジーの 特別なリストに格納することができます。この場合、任意のストラテジーはEventProcessorによって生成された新しいイベントを受信することが できます。次の図は、イベントが生成され、送信される方法を示しています。

図1。イベント生成と送信のダイアグラム

作者: Vasiliy Sokolov

 
著者に感謝する。記事の素材は非常に有用であり、また見事に表現されている。私は長い間、専門的な文章を書くためのアプローチを整えたいと思っていたが、この記事の著者はすでに創造性のすべての痛みを経験し、既製の解決策を提供している。素晴らしい!続きが楽しみだ。


トレーディング・ システム自動 化の道なき道、創造性の苦悩、開発者の「トレーディング・ エンジン」に対する気の緩みにぶつかってみよう!

 

著者の有益な記事に感謝しますが、ソフトウェア実装の信頼性に疑問があります。

提案されているコードでは、すべてのイベント・ハンドラ関数は共通のevent_type変数を参照するか、CStrategyの 共通のインスタンス内のm_event構造体を参照しています。

しかし、これは危険です。イベントが非同期に発生し、そのハンドラのスレッドが時間的に重なり、共通のデータが無秩序に変更されたり、同じメモリ領域にアクセスする際に障害が発生したりする可能性があるからです。

通常、スレッドの同期はセマフォ、ミューテックス、ウェイト関数、クリティカル・コード・セクションなどを使用して実行されますが、MQLにはそのような手段がないため、非同期イベントの関数ハンドラでは、オブジェクトや変数のグローバル・インスタンスへの参照を最小限に抑え、ローカルなものを使用するようにする必要があることは明らかです。

この点を踏まえると、この記事で提案されているイベント・ハンドラとデータ・ブロックの組み合わせは、IMHOとしては良いアイデアとは言えない。

 
Eugene Myzrov:
著者に感謝する。記事の素材は非常に有用であり、また見事に表現されている。私は長い間、専門的な文章を書くためのアプローチを整えたいと思っていたが、この記事の著者はすでに創造性のすべての痛みを経験し、既製の解決策を提供している。素晴らしい!続きが楽しみだ。


トレーディング・システム自動化の道なき道、創造性の苦悩、開発者の「トレーディング・エンジン」に対する気の緩みにぶつかりましょう!

ありがとうございました!

Ivan Negreshniy:

有益な記事を書いてくれた著者に感謝しますが、ソフトウェア実装の信頼性については疑問があります。

提案されたコードでは、すべてのイベント・ハンドラ関数は共通のevent_type変数またはCStrategyの共通のインスタンス内のm_event構造体を参照しています。

しかし、これは危険かもしれない。イベントは非同期に発生し、ハンドラーのスレッドが時間的に重なり、共通のデータが無秩序に変更されたり、同じメモリ領域にアクセスする際に障害が発生したりする可能性があるからだ。

...

興味深いご指摘ありがとうございます。確かにMetaTraderのイベントは非同期です。しかし、ユーザースレッドの実行は厳密にシーケンシャルです。つまり、Expert Advisorが現在のイベントの処理を終了するまで、他のイベントは処理されません。下のコードはこの点を示しています:

//+------------------------------------------------------------------+
//|TestAsynch.mq5
//|著作権 2015, Vasiliy Sokolov.|
//|http://mql5.commql5.com
//+------------------------------------------------------------------+
#property copyright "Copyright 2015, Vasiliy Sokolov."
#property link      "http://www.mql5.com"
#property version   "1.00"
bool need_check = true;
#define  EVENT_CHECK_ASYNCH 1
//+------------------------------------------------------------------+
//| エキスパート・ティック機能|
//+------------------------------------------------------------------+
void OnTick()
  {
//---
   if(need_check)
   {
      EventChartCustom(ChartID(), EVENT_CHECK_ASYNCH, 0.0, 0.0, "非同期チェック");
   }
   if(need_check)
      printf("ユーザー・スレッドが最初に終了する");
  }
//+------------------------------------------------------------------+
//| チャートイベント機能|
//+------------------------------------------------------------------+
void OnChartEvent(const int id,
                  const long &lparam,
                  const double &dparam,
                  const string &sparam)
  {
//---
   if(id == CHARTEVENT_CUSTOM+EVENT_CHECK_ASYNCH && need_check)
   {
      printf(「そしてOnChartEventイベントが呼ばれる。);
      need_check = false;
   }
  }
//+------------------------------------------------------------------+

その実行は以下の順序で行を生成します:

2016.01.15 13:51:31.724 TestAsynch (NZDUSD,W1)  Потом вызывается событие OnChartEvent
2016.01.15 13:51:31.722 TestAsynch (NZDUSD,W1)  Сначала завершается пользовательский поток

このように、コードが順次実行されるため、 共有変数m_eventの 共同変更によるエラーは発生しません。また、構造体自体はプライベートであり、特別なメソッドへの参照によってのみアクセス可能であることにも注意しなければならない。したがって、CStrategy 内部の実際の位置は問題ではなく、構造体はイベントハンドラメソッドで簡単に直接作成でき、ストラテジーインスタンスにも渡すことができます。

 
Vasiliy Sokolov:

ありがとう!

興味深い見解をありがとう。確かにMetaTraderのイベントは非同期です。しかし、ユーザースレッドの実行は厳密にシーケンシャルです。つまり、Expert Advisorが現在のイベントの処理を終了するまで、他のイベントは処理されません。下のコードはこの点を示しています:

その実行は以下の順序で行を生成します:

このように、コードが順次実行されるため、 共有変数m_eventの 共同変更によるエラーは発生しません。また、構造体自体はプライベートであり、特別なメソッドへの参照によってのみアクセス可能であることにも注意しなければならない。したがって、CStrategy内部の実際の位置は問題ではなく、構造体はイベントハンドラメソッドで簡単に直接作成でき、ストラテジーインスタンスにも渡すことができます。

イベントハンドラを厳密に逐次実行することでエラーをなくすことができるのはその通りだが、これは本質的にシングルスレッド・モードであり、高いパフォーマンスを達成するのは難しい。

同時に、並列化を必要とするタイムクリティカルなタスクもあります。例えば、OpenCLを使って実行される大量の価格とヒストリカルデータを使った計算や、私の記事で紹介したマルチスレッドエンジンの助けを借りて実行される、異なるシンボルと期間に対するニューラルネットワークのトレーニングなどです。
https://www.mql5.com/ja/articles/706

Создание нейросетевых торговых роботов на базе MQL5 Wizard и Hlaiman EA Generator
Создание нейросетевых торговых роботов на базе MQL5 Wizard и Hlaiman EA Generator
  • 2013.08.29
  • Ivan Negreshniy
  • www.mql5.com
В статье рассматривается метод автоматизированного создания нейросетевых торговых роботов на базе MQL5 Wizard и Hlaiman EA Generator. Узнайте, как легко начать работать с нейронными сетями, минуя длительные этапы изучения теоретических материалов и написания собственного кода.
 
Ivan Negreshniy:

おっしゃる通り、イベント・ハンドラを厳密に逐次実行すればエラーはなくなりますが、これは基本的にシングル・スレッド・モードであり、高いパフォーマンスを達成するのは困難です。

同時に、並列化を必要とするタイムクリティカルなタスクも存在します。例えば、OpenCLを使用して実行される大量の価格とヒストリカルデータを使用した計算や、私の記事に記載されているマルチスレッドエンジンの助けを借りて実行される、異なるシンボルと期間によるニューラルネットワークのトレーニングなど、私にとってはより具体的なタスクです。
https://www.mql5.com/ja/articles/706

MetaTraderの並列化はマルチスレッドのストラテジーテスターによって行われます。したがって、説明したエンジンの助けを借りて書いたストラテジーをストラテジーテスターで実行すると、自動的にマルチスレッドになります。サードパーティのDLLがないので、MQL Networl Cloudをフルに使うことができます。MetaTrader本体についてお書きになっていますが。はい、エンジンはMetaTraderのExpert Advisorやスクリプトと同様にシングルスレッドですが、オプティマイザを使用することで、提示されたコードのマルチスレッドやクラウドコンピューティングを実行することができます。

エンジンのパフォーマンスそのものは問題ありません。プロファイリングを実行することで確認できます。インフラとイベント配信のコストは最小限です。主な実行時間は、システム関数とカスタムメソッドBuyInit、SellInit、BuySupport、SellSupportの呼び出しに集中しています。プロファイリング計算に基づくと、このエンジンは1秒間に何十ものイベントを処理することができ、同時に複数のストラテジーに難なくリダイレクトします。

この記事で提供されているのは、申し訳ないが、指弾するようなものではない。数年にわたり検証され、テストされたソリューションである。すべてのコールと内部プロシージャーは最適かつ重要である。アルゴリズムはプロファイラーでテストされている。ユーザーコードの内部構成に制限はない。一般的に、完全な幸福のためのすべてがあります。使ってみてください。

 
Vasiliy Sokolov 氏の一般的な良いプログラミングスタイル、特にOOPを広めるための努力に 感謝 します。
記事は明確に述べられており、少なくとも私がそうであるMQL初心者にとっては非常に有益です。

私の取引アルゴリズムでは、
買い/売りタイプの成行注文による ポジションは 、価格が対応するレベルをすでに通過している場合、または 取引セッションの終了前という特別な状況でオープンされます。
通常、ポジションは、新しいバーの開始時に再計算される逆指値注文(BuyStop/SelStop)を発注することで、(ロングの場合)上下レベルのブレイクダウン時にオープン/クローズされます。
説明されているクラスに逆指値注文の発注と変更を導入することが可能な方法をご教示いただけますか?
 
Mike:
Vasiliy Sokolov 氏の一般的な良いプログラミングスタイル、特にOOPを広めるための努力に 感謝 します。 この記事は明確に述べられており、少なくとも私がそうであるMQL初心者にとっては非常に有益です。 私の取引アルゴリズムでは、


買い/売りタイプの成行注文による ポジションは 、価格が対応するレベルをすでに通過している場合、または 取引セッションの終了前という特別な状況でオープンされます。
通常、ポジションは、新しいバーの開始時に再計算されるBuyStop/SelStop逆指値注文を 発注することで、(Longの場合)上下レベルのブレイクダウンでオープン/クローズされます。
説明されているクラスに逆指値注文の発注と変更を導入する方法を教えてください。

こんにちは。現在、未決注文を管理するためのアルゴリズムが研究されていますが、現在のバージョンのエンジンにはまだ具体的な実装がありません。今のところ私が提案できる唯一のことは、BuyInitメソッドとSellInitメソッドに未決注文を置くコードを配置することです。また、保留中の注文をそこで列挙し、通常のExpert Advisorで行わなければならないすべてのアクションを行う必要があります。

将来的には、保留中の注文を処理するメソッドをエンジンに追加し、対応する説明を作成する予定です。それらはポジション管理メソッドと同様に機能する。

 
Vasiliy Sokolov:

こんにちは。現在、未決済注文管理のアルゴリズムが研究されていますが、現在のバージョンのエンジンには具体的な実装がありません。現時点で私が提案できる唯一のことは、BuyInitメソッドとSellInitメソッドに未決注文を置くコードを配置することです。また、保留中の注文をそこで列挙し、通常のExpert Advisorで行わなければならないすべてのアクションを行う必要があります。

将来的には、保留中の注文を処理するメソッドをエンジンに追加し、対応する説明を作成する予定です。これらはポジション管理メソッドと同様に機能します。

ありがとう、Vasily。:)
 
ヴァシリー、記事をどうもありがとう!初心者にとても役立つ記事です!
 

感謝

*****