記事"MQL5オブジェクト指向のプログラミングアプローチを使ったExpert Advisorのプログラミング"についてのディスカッション

 

新しい記事 MQL5オブジェクト指向のプログラミングアプローチを使ったExpert Advisorのプログラミング はパブリッシュされました:

本稿では初心者のためのAdvisor in MQL5でプログラミングをする段階的ガイドで行ったこと、すなわちExpert Advisor作成に対してオブジェクト指向のアプローチに注目します。ほとんどの方はこれは難しいと思われるでしょう。しかし本稿を読み終わるまでにみなさんはブジェクト指向でExpert Advisorを書けるようになっている、という点をはっきり述べておきたいと思います。

クラスメンバーー関数

作者: Samuel

 

一般的には悪くはないが、名前に使われているOOPのスローガンに従うには少しお粗末だ。例えば、なぜストップロス、テイク、プライスがクラスの外に置かれているのか?STPとTKPはメンバーであるべきで、setSLTPメソッドが必要だ。latest_priceとlevelsはopenBuy/openSellの中で考えるべきだ。MarginOKコールのあるifを1つだけ残し、その中にif(Chk_Margin == 0) return(true)というチェックの最初の行を追加するのが望ましい;

そして、もう一つ小さなことがあります。Chk_Marginはboolとしてしか使われていないのに、なぜint-として宣言されているのでしょうか?そうでないと、ソース・コードを読むときに、Chk_Margin== 2や3などの場合はどうなるのだろうという疑問が生じます。

 
指定された期間の指定されたペアで、デフォルトの入力パラメータでは、このような美しいバランス・チャートは得られない。作者には他の引用がありましたか?そのようなチャートが得られた入力パラメーターを添付してもらえますか?
 
capr:
指定された期間の指定されたペアで、デフォルトの入力パラメータでは、このような美しいバランス・チャートは得られない。作者には他の引用がありましたか?そのようなチャートが得られた入力パラメーターを添付してもらえますか?

結果が大きく異なるためには、あなたと作者の相場はどの程度異なる必要があるのでしょうか?)私はほとんど同じ結果を得ました:

 

デザインが不可解

   if(Buy_Condition_1 && Buy_Condition_2 && Buy_Condition_3 && Buy_Condition_4)
     {
       return(true);
     }
     else
     {
       return(false);
     }
 
ortv:

デザインが不可解

具体的に何がそんなに気に入らないのですか?もちろん、コードの文脈で見たことはありませんが......。
 
Interesting:
具体的に何がそんなに嫌なんですか?もちろん、コードの文脈で見たわけではありませんが......。

こういう場合、普通はこう書くんじゃないですか?

return(Buy_Condition_1 && Buy_Condition_2 && Buy_Condition_3 && Buy_Condition_4);
 
ortv:

こういう場合、普通はこう書くのでは?

コードが忠実に再現されていて、他に処理に何もなければ、この方法でもいいのですが...。
 

コードの以下の部分が理解できません:

// 直前のバー(バー1)の終値を、対応するExpert Advisor変数にコピーする。
   Cexpert.setCloseprice(mrate[1].close);  // バー1の終値
//--- 買いポジションがあるかどうかをチェックする
   if (Cexpert.checkBuy()==true)
   {
      if (Buy_opened) 
         {
            Alert("すでに買うポジションがある!"); 
            return;    // ロング・ポジションに追加しない
         }
      double aprice = NormalizeDouble(latest_price.ask,_Digits);
      double stl    = NormalizeDouble(latest_price.ask - STP*_Point,_Digits);
      double tkp    = NormalizeDouble(latest_price.ask + TKP*_Point,_Digits);
      int    mdev   = 100;
      // 注文する
      Cexpert.openBuy(ORDER_TYPE_BUY,Lot,aprice,stl,tkp,mdev);
   }
買いポジションを建てる場合、latest_price.ask 価格に注目すべきですが、そのようなポジションのストップロスとテイクプロフィットを設定する場合、latest_price.bid 価格に注目すべきです。これは正しいですか?なぜストップロスとテイクプロフィットはコードテキスト内の売値に基づいて設定されるのですか?これは誤植なのでしょうか、それとも特定のストラテジーの特殊性なのでしょうか。
 
Yedelkin:

コードの以下の部分が理解できません:

買いポジションを建てる場合、latest_price.ask 価格に注目すべきですが、そのようなポジションのストップロスとテイクプロフィットを設定する場合、latest_price.bid 価格に注目すべきです。これは正しいですか?では、なぜストップロスとテイクプロフィットは、コードテキストでは売値に基づいて設定されるのでしょうか?これは誤植なのでしょうか、それとも特定のストラテジーの特殊性なのでしょうか。

以下はそのロジックです(たぶん、私も普段使っています):

1.買いの始値は Askと考える(そしてそれは正しい);

例えば、EURUSDの1.27でオープンするとします。

2.2.ポジションを建てる際、スプレッドに等しい差額を得ますが、買いの場合、それはAsk-Bidです(現在の価格で決済した場合、損失が発生する可能性があります);

スプレッドを5ピップスと仮定します。したがって、オープン時のBidは1.2695となります。

3.ロングはビッド価格でクローズします(これは極めて論理的です)。

したがって、Bidが1.27になると、そのポジションはBUとなる。

4.しかし、利益を得る必要もある(標準的な相場では100ピップス)。

つまり、TPはOpenより100pips高くなければなりません。私たちの場合、それは1.28です。

同時に、Bid(Askではない)がこの1.28に達すると、TPがトリガーされます。

5.SLも設定する必要があります(仮に50pipsとします)。つまり、この例では1.2650(オープンから50ピップス下)になります。

SLはどのような条件で機能しますか?

論理的には、価格がこの50pipsを通過したときに機能するはずです(つまり、SLの終値コインのAskは、論理的にはこの1.2650にあるはずです)。

この場合、Bidはどこにあるべきでしょうか?そしてこの時、それは1.2645に位置することになります(条件によって5ピップス持っているため)。

ロングは固定であることを忘れない。

6.では、実際に何が起きているのかを見てみましょう(MQL4でロングのマーケット・オープニングを例にとってみましょう)。

//Взято из справки по OrderSend
 ticket=OrderSend(Symbol(),OP_BUY,1,Ask,3,Bid-25*Point,Ask+25*Point);

ここでわかること

始値がAsk、SLがBid、TPがAskとみなされます。

私たちの場合、このようなパターンになります。

OrderSend(Symbol(),OP_BUY,1,Open = Ask,3,SL = Bid-50*Point,TP Ask+100*Point);

ここに我々のデータを代入してみましょう:

OrderSend(Symbol(),OP_BUY,1,1.2700,3,1.2695-50*Point,TP 1.2700+100*Point);

オープン = 1.2700 SL = 1.2645 TP 1.28

PS

元のデータと比較してみましょう:

注文 - オープン = 1.2700 SL= 1.2645 TP 1.28

モデル - オープン = 1.2700 SL= 1.2645 TP 1.28

 
Interesting:

ここにはこんな論理がある(もっとも、私も使いがちだが):

1.買いの始値は Askとみなされる(そしてそれは正しい);

EURUSDの1.27で始まるとしよう。

2.ポジションを建てる際、スプレッドに等しい差額を得ることができ、買いの場合はAsk-Bidとなります(現在の価格で決済した場合、損失が発生する可能性があります);

スプレッドを5ピップスと仮定します。したがって、オープン時のBidは1.2695になります(よね?)

5.SLも設定する必要があります(50ピップスとします)。つまり、この例では1.2650(オープンから50ピップス下)になります。

SLはどのような条件でトリガーされますか?

論理的には、価格がこの50pipsを通過したときに機能するはずです(つまり、SLの終値コインのAskは、論理的にはこの1.2650にあるはずです)。

この場合、Bidはどこにあるべきでしょうか?そしてこの時、それは1.2645に位置することになります。

ロングは固定であることを忘れないでください。

オープン時のBidが1.2695であれば、すでに5pipsの損失が自動的に発生します。同時に、開発者の考えに従ってSLが50ピップスだとすると、それがトリガーされるまでに、不利な方向にあと45ピップス進むことになります。つまり、ストップロスがトリガーされるとき、ビッドは1.2645ではなく1.2650に、アスクはそれぞれ1.2655にあるはずです。