EA作成時に有線移動平均の問題が発生しました。 - ページ 3

新しいコメント
 
angreeee:
2009年から現在(2014年4月)の日付で実行しても、チャート上のMAとバックテストのimaの差は0.10のままなので、問題は解決していないようです。icustomは2009年から始めてもD1チャートでは0しか返さず、H4チャートでは正常に動作しています。
先ほどSMMAモードに問題があることを確認しましたが、すでにサービスデスクに報告したのではありませんか？他のモードは問題ないようです。
 

カスタム移動平均 インジケータがどのように動作するかを分析すると、なぜそのような問題が発生するのかがわかります。

すべての移動平均は、式に必要な（この場合は370）フレームを数えるのではなく、移動平均の前のフレームから次のフレームを数えるという、粗雑でない方法でカウントされています。そうすることで、もしMAの1フレームが不正確であれば、その次のフレームもすべて不正確となります。エラーフレームから離れれば離れるほど、誤差は小さくなります。最初からすべてのフレームが正しくカウントされていれば、正しく動作することも可能ですが、iMAの開始時にゼロを報告することがあり（私は誤ったMAの読み取りを破棄する手順を持っていますが、iMA自体はそうしません）、これらのゼロはおそらくiMAの前のフレームから次のフレームを数える際にも考慮されることに気づきました。
そのため、2013年にバックテストを開始したときが最も差が大きく、2012年は2013年に開始したときよりも小さく、start=2011年はさらに小さく、といった具合になります。2009年からバックテストを開始しても、その差は歴然としていましたので、これは深刻な問題です。

 
angevoyageur:
先ほどSMMAモードに問題があることを確認しましたが、すでにサービスデスクに報告されたと思いますが？他のモードは問題ないようです。

この問題を完全に文書化し理解するために、私自身のiMA交換手順を書き終えています。(このスレッドで行われたような視覚的な比較だけでなく）。

imaの結果、私のimaの置き換えとカスタム移動平均の 結果は、比較のためにログで利用できるようになる予定です。

PS.もしあなたがエラーを確認したら、私は今それを報告しています。(問題が報告されたら、このスレッドに新しいコメントを追加します）。現在、サイト（あるいは私のインターネット）の動作が非常に遅いので、サービスデスクのページにたどり着くことさえ問題があります。
 
OK 報告されています。
 

他のMAタイプも影響を受けると思っていましたが、さらにテストをしてみたところ、おっしゃるとおりSSMAだけが影響を受けているようです。

しかし、iCustomの問題には気づきました。SSMAとiCustomの問題をテストするためのスクリプトです。

#property version     "1.1"
#property description "MA TEST"

#include <Trade/Trade.mqh>

   #define  MAGICMA  20131002

double Bid;
double Ask;

   int ma_temp;
   int custom_ma_temp;
   double ma_buffer[20];
   double ima2_buffer[510];
   double ima2[510];

input int ma_period = 370;
input ENUM_TIMEFRAMES ma_tf = PERIOD_D1;
input ENUM_MA_METHOD ma_method = MODE_SMMA;
input ENUM_APPLIED_PRICE ma_price = PRICE_OPEN;
   
   
   
double OnTester()
{
    double custommax = TesterStatistics(STAT_EQUITY_DDREL_PERCENT);
    return (custommax);
}
   CTrade  trade;
   
  void OnTick()
  {
   MqlTick last_tick;
   if(SymbolInfoTick(Symbol(),last_tick))
     {
      Bid = last_tick.bid;
      Ask = last_tick.ask;
     }
   start();
  }
  
int OnInit()
  {
   trade.SetExpertMagicNumber(MAGICMA);
   int deviation=99;
   trade.SetDeviationInPoints(deviation);
   trade.SetAsyncMode(false);

   return(0);
  }  
  
      
      
      
void trend1()
{

   double ma;

   ma_temp=iMA(Symbol(),ma_tf,ma_period,0,ma_method,ma_price);
   CopyBuffer(ma_temp,0,0,1,ma_buffer);
   ma=ma_buffer[0];
   Alert("ma=", ma);

   custom_ma_temp=iCustom(Symbol(),ma_tf,"Examples\\Custom Moving Average", ma_period, 0, ma_method,ma_price);
   CopyBuffer(custom_ma_temp,0,0,1,ma_buffer);
   ma=ma_buffer[0];  
   Alert("custom ma=", ma);

}

      


void start()
{
         trend1();
}
ファイル:
icustom_problem.png  143 kb
 
angreeee:

カスタム移動平均インジケータがどのように動作するかを分析すると、なぜそのような問題が発生するのかがわかります。

すべての移動平均は、式に必要な（この場合は370）フレームを数えるのではなく、移動平均の前のフレームから次のフレームを数えるという、粗雑でない方法でカウントされています。そうすることで、もしMAの1フレームが不正確であれば、その次のフレームもすべて不正確となります。エラーフレームから離れれば離れるほど、誤差は小さくなります。最初からすべてのフレームが正しくカウントされていれば、正しく動作することも可能ですが、iMAの開始時にゼロを報告することがあり（私は誤ったMAの読み取りを破棄する手順を持っていますが、iMA自体はそうしません）、これらのゼロはおそらくiMAの前のフレームから次のフレームを数える際にも考慮されることに気づきました。
そのため、2013年にバックテストを開始したときが最も差が大きく、2012年は2013年に開始したときよりも小さく、start=2011年はさらに小さく、といった具合になります。2009年からバックテストを開始しても、その差は歴然としていましたので、深刻な問題です。

iMAはパフォーマンス重視で設計されています。もしiMAが0を報告したら、それはデータがない（あるいは十分なデータがない）ためです。ところで、SMMAにだけ問題があります。なぜかわかりませんが、他のモードではうまくいっているので、この「インクリメンタル」な実装が原因であることはないでしょう。
 
angevoyageur:
I don't see the problem. iMA is well coded for performance. If an iMA report a 0 it's because you don't have data (or enough data). By the way there is only a problem with SMMA, I don't know why, but it cannot be due to this "incremental" implementation as it's working well for other mode.

そうですね、もっと遅くなりますね。しかし、実際、このカウント方法に加え、最初にいくつかの空のフレーム（ゼロ）があると、このような問題が発生します。(iMAのSSMAは常に小さく、実際のSSMAより大きくないのはそのためです）iMAが返すものをチェックしないので、必要な情報の欠如を適切に処理する代わりに、最初にゼロが出るのは知っていますが、これは別の問題です。

小さいTFでは、分析されるフレーム数が多く、問題は時間の経過とともに薄れていくかもしれません。新しいフレームが増えるごとに、イマSSMAは本物のSSMAに近づいていくので、バーを重ねれば重ねるほど、問題は見えにくくなり、そのため、これまで誰も気づかなかったのだと思います。同じ問題が370 SSMAとPERIOD_12H PERIOD_8Hなどでも見つかりました。

もしお時間があれば、iCustom関数を調べてみてください。簡単にテストできるようにソース コードを添付しておきます。PERIOD_D1 - iCustomは正常に動作し、iMAと同じ値を返すことを任意の下位TFを確認してください。PERIOD_D1ではiCustomは常にゼロですが、iMAはまだいくつかの値を報告しています。

不思議なのは、SSMAを最大PERIOD_H12で使用すると、iMAとiCustomの両方の「カスタム移動平均」インジケータが誤った値を報告することです。(違いを見るために2014.01からテストしています)

エラーはこの辺にあるはずです。(フォームカスタム移動平均)

void CalculateSmoothedMA(int rates_total,int prev_calculated,int begin,const double &price[])
  {
   int i,limit;
//--- first calculation or number of bars was changed
   if(prev_calculated==0)
     {
      limit=InpMAPeriod+begin;
      //--- set empty value for first limit bars
      for(i=0;i<limit-1;i++) ExtLineBuffer[i]=0.0;
      //--- calculate first visible value
      double firstValue=0;
      for(i=begin;i<limit;i++)
         firstValue+=price[i];
      firstValue/=InpMAPeriod;
      ExtLineBuffer[limit-1]=firstValue;
     }
   else limit=prev_calculated-1;
//--- main loop
   for(i=limit;i<rates_total && !IsStopped();i++)
      ExtLineBuffer[i]=(ExtLineBuffer[i-1]*(InpMAPeriod-1)+price[i])/InpMAPeriod;
//---
  }

firstValueはSMAの手順と同じようにカウントされることに注意してください。

void CalculateSimpleMA(int rates_total,int prev_calculated,int begin,const double &price[])
  {
   int i,limit;
//--- first calculation or number of bars was changed
   if(prev_calculated==0)// first calculation
     {
      limit=InpMAPeriod+begin;
      //--- set empty value for first limit bars
      for(i=0;i<limit-1;i++) ExtLineBuffer[i]=0.0;
      //--- calculate first visible value
      double firstValue=0;
      for(i=begin;i<limit;i++)
         firstValue+=price[i];
      firstValue/=InpMAPeriod;
      ExtLineBuffer[limit-1]=firstValue;
     }
   else limit=prev_calculated-1;
//--- main loop
   for(i=limit;i<rates_total && !IsStopped();i++)
      ExtLineBuffer[i]=ExtLineBuffer[i-1]+(price[i]-price[i-InpMAPeriod])/InpMAPeriod;
//---
  }

最初の値 = (x1 + x2 + x3 + ... + xn) / nとして

これは単純移動平均の「粗い」式であり、平滑化移動平均のものではありません。

これが問題の原因なのでしょうか？

 

をそのサイトよりご覧ください。

https://mahifx.com/indicators/smoothed-moving-average-smma

Smoothed Moving Averageの最初の値は、Simple Moving Average (SMA)として計算されます。

sum1=sum (close, n)

smma1 = sum1/ n

2回目以降の移動平均は、この式に従って計算されます。

SMMA (i) = (SUM1 - SMMA1+CLOSE (i))/ N

ここで

SUM1 - N期間の終値の合計です。
SMMA1 - 最初のバーの平滑化された移動平均です。
SMMA (i) - 現在のバーの平滑化移動平均（最初のバーを除く）です。
CLOSE (i) - 現在の終値です。
N - 平滑化期間です。

ということは、iMaやカスタム移動平均は正しい方法で計算されているのでしょう。しかし、そのような計算をすると、今回のようなエラーが発生し、テストする期間によって大きな差が生じます。移動平均をベースにしたEAとしては全くもって許せません。そのため、私のEAではSmoothed MAはバックテスト時に不具合が発生するため、排除せざるを得ないようです。2000年からテストしてうまくいっても、2013年からテストして「口座がパンクした」と言われるかもしれませんし、私とは別のSSMAが表示されますから。

もう1つ引用します。
SMMAでは、直近の価格が過去の価格と同等の加重を持ちます。計算では、固定期間を参照するのではなく、利用可能なすべてのデータシリーズを考慮します。

そのため、バックテスト期間が変わるたびに異なる値になります。

Indicators
Indicators
  • mahifx.com
Moving averages are commonly used to identify trends and reversals as well as identifying support and resistance levels. Moving averages such the WMA and EMA, which are more sensitive to recent prices (experience less lag with price) will turn before an SMA. They are therefore more suitable for dynamic trades, which are reactive to short term...
 
angreeee:

引用の中に返信しないでください。ご覧の通り、引用したい時は空欄になりました。

アルゴリズムはSMMAに適しています、あなたはどこかで開始する必要があります。しかし、あなたは問題の原点を指摘している、SMMAは前の値に基づいて構築されているように、それは開始条件に敏感である。ライブチャートとストラテジーテスターで 同じスタートローソク足がないため、値が異なるのはそのためです。

EMAについても同様で、（D1で）再度確認したところ、SMMAと同様に異なる値が出ています。

 
angreeee:

をそのサイトよりご覧ください。

https://mahifx.com/indicators/smoothed-moving-average-smma

Smoothed Moving Averageの最初の値は、Simple Moving Average (SMA)として計算されます。

sum1=sum (close, n)

smma1 = sum1/ n

2回目以降の移動平均は、この式に従って計算されます。

SMMA (i) = (SUM1 - SMMA1+CLOSE (i))/ N

ここで

SUM1 - N期間の終値の合計です。
SMMA1 - 最初のバーの平滑化された移動平均です。
SMMA (i) - 現在のバーの平滑化移動平均（最初のバーを除く）です。
CLOSE (i) - 現在の終値です。
N - スムージング期間です。

ということは、iMaやカスタム移動平均は正しい方法で計算されているのでしょう。しかし、そのような計算をすると、今回のようなエラーが発生し、テストする期間によって大きな差が生じてしまいます。移動平均をベースにしたEAとしては全くもって許せません。そのため、私のEAではSmoothed MAはバックテスト時に不具合が発生するため、排除せざるを得ないと思います。2000年からテストしてうまくいったとしても、2013年からテストして「口座が消えた」と言われるかもしれません。

リンクありがとうございます。これは私の以前の投稿を確認するものです。私はそのようなことに注意を払うことはありませんように、それは非常に興味深いです。

EMAのアルゴリズムを確認すると、このような問題にも敏感で、なぜ私の最初のテストが同じ値を得たのかが分かりません。

1234
新しいコメント