Mit verdrahtetem gleitendem Durchschnitt Problem beim Erstellen von EA.. - Seite 3

Neuer Kommentar
 
angreeee:
Ich bemerkte wieder, auch wenn ich es von 2009 zum aktuellen Datum (04.2014) die Differenz zwischen der MA auf dem Chart und ima in Backtest ist immer noch 0,10, so dass ich denke, das Problem bleibt. Ich werde meine eigene iMa-Ersatzfunktion machen, wenn alle anderen fehlgeschlagen sind. icustom gibt immer noch nur Nullen im D1-Chart zurück, selbst wenn ich mit 2009 beginne, und funktioniert gut im H4-Chart.
Ich habe vorhin bestätigt, dass es ein Problem mit dem SMMA-Modus gibt, ich denke, Sie haben das bereits dem Service Desk gemeldet? Die anderen Modi scheinen mir in Ordnung zu sein.
 

Wenn ich analysiere, wie derbenutzerdefinierte gleitende Durchschnittsindikator funktioniert, verstehe ich, warum es solche Probleme gibt.

Jeder gleitende Durchschnitt wird in nicht grober Weise gezählt, indem der nächste Frame des gleitenden Durchschnitts vom vorherigen Frame des gleitenden Durchschnitts abgezogen wird, anstatt nur die notwendigen (in diesem Fall 370) Frames für die Gleichung zu zählen. Auf diese Weise werden, wenn 1 Frame des gleitenden Durchschnitts falsch ist, alle folgenden ebenfalls falsch sein. Je weiter der Fehler-Frame entfernt ist, desto geringer ist der Fehler. Es könnte sogar richtig funktionieren, wenn alle Frames von Anfang an richtig gezählt würden, aber mir ist aufgefallen, dass iMA am Anfang manchmal Nullen meldet (ich habe ein Verfahren, um fehlerhafte MA-Messwerte zu verwerfen, aber die iMA selbst tut das nicht), und diese Nullen werden wahrscheinlich auch bei der Zählung der nächsten Frames von iMA von den vorherigen Frames von iMA berücksichtigt.
Deshalb war der Unterschied am größten, als ich 2013 mit den Backtests begann, 2012 war er kleiner als beim Start 2013, bei Start=2011 sogar noch kleiner, und so weiter. Der Unterschied war auch dann noch sichtbar, als ich mit dem Backtest 2009 begann, es handelt sich also um ein ernstes Problem.

 
angevoyageur:
Ich habe bereits bestätigt, dass es ein Problem mit dem SMMA-Modus gibt. Ich glaube, Sie haben dies bereits dem Service Desk gemeldet. Andere Modi scheinen mir in Ordnung zu sein.

Ich schreibe gerade mein eigenes iMA-Austauschverfahren, damit ich das Problem vollständig dokumentieren und verstehen kann. (nicht nur durch visuelle Vergleiche wie in diesem Thread getan).

Die Ergebnisse von ima, meine ima Ersatz und benutzerdefinierte gleitenden Durchschnitt Ergebnisse werden in das Protokoll für den Vergleich zur Verfügung stehen.

PS: Wenn Sie den Fehler bestätigen, werde ich ihn jetzt melden. (Ich werde einen neuen Kommentar in diesem Thread hinzufügen, wenn das Problem gemeldet ist). Die Website (oder mein Internet) arbeitet im Moment sehr langsam, so dass ich Probleme habe, überhaupt auf die Seite des Service Desk zu gelangen.
 
ok es wird berichtet.
 

Ich dachte, andere MA-Typen sind auch betroffen, aber ich habe mehr Tests gemacht und SSMA scheint der einzige, der betroffen ist, wie Sie gesagt haben.

Aber ich habe ein iCustom-Problem festgestellt. Skript, um SSMA und iCustom Probleme zu testen:

#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();
}
Dateien:
icustom_problem.png  143 kb
 
angreeee:

Wenn ich analysiere, wie der benutzerdefinierte gleitende Durchschnittsindikator funktioniert, verstehe ich, warum es solche Probleme gibt.

Jeder gleitende Durchschnitt wird in nicht grober Weise gezählt, indem der nächste Frame des gleitenden Durchschnitts vom vorherigen Frame des gleitenden Durchschnitts abgezogen wird, anstatt nur die notwendigen (in diesem Fall 370) Frames für die Gleichung zu zählen. Auf diese Weise werden, wenn 1 Rahmen des gleitenden Durchschnitts fehlerhaft ist, alle folgenden ebenfalls fehlerhaft. Je weiter der Fehler-Frame entfernt ist, desto kleiner ist der Fehler. Es könnte sogar richtig funktionieren, wenn alle Frames von Anfang an richtig gezählt würden, aber mir ist aufgefallen, dass iMA am Anfang manchmal Nullen meldet (ich habe ein Verfahren, um fehlerhafte MA-Messwerte zu verwerfen, aber die iMA selbst tut das nicht), und diese Nullen werden wahrscheinlich auch bei der Zählung der nächsten Frames von iMA von den vorherigen Frames von iMA berücksichtigt.
Deshalb war der Unterschied am größten, als ich 2013 mit den Backtests begann, 2012 war er kleiner als beim Start 2013, bei Start=2011 sogar noch kleiner, und so weiter. Der Unterschied war auch dann noch sichtbar, als ich mit dem Backtest 2009 begann, es handelt sich also um ein ernstes Problem.

Ich sehe das Problem nicht. iMA ist gut auf Leistung kodiert. Wenn ein iMA eine 0 meldet, liegt das daran, dass Sie keine Daten (oder nicht genug Daten) haben. Übrigens gibt es nur ein Problem mit SMMA, ich weiß nicht, warum, aber es kann nicht an dieser "inkrementellen" Implementierung liegen, da sie für andere Modi gut funktioniert.
 
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.

Ja, du hast recht, es wäre viel langsamer. Aber die Tatsache ist, dass diese Art der Zählung plus einige leere Frames (Nullen) am Anfang Probleme wie diese führen würde. (Das ist, warum iMA SSMA ist immer kleiner, nicht größer als die tatsächliche SSMA) Ich weiß, ich nicht überprüfen, was iMA zurückgibt, dass ist, warum ich Nullen am Anfang erhalten, anstatt den Mangel an notwendigen Informationen richtig zu behandeln, aber das ist ein anderes Thema.

Bei kleineren TFs werden viel mehr Frames analysiert und das Problem kann mit der Zeit verwässert werden. Mit jedem neuen Frame nähert sich der ima SSMA immer mehr dem realen SSMA an, so dass das Problem umso weniger sichtbar ist, je mehr Bars vergangen sind. Das gleiche Problem fand ich mit 370 SSMA und PERIOD_12H PERIOD_8H, etc.

Wenn Sie Zeit haben, schauen Sie sich bitte die iCustom-Funktion an. Ich habe den Quellcode angehängt, um ihn leicht zu testen. Überprüfen Sie alle niedrigeren TFs, die PERIOD_D1 - iCustom funktioniert gut und gibt die gleichen Werte wie iMA. In PERIOD_D1 ist es immer Nullen für iCustom, während iMA noch einige Werte meldet.

Das Merkwürdige ist, wenn Sie SSMA auf max PERIOD_H12 sowohl iMA und iCustom "benutzerdefinierte gleitenden Durchschnitt" Indikator Bericht fehlerhafte Werte. (Test ab 2014.01, um den Unterschied zu sehen)

Der Fehler muss hier irgendwo liegen: (form custom moving average)

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;
//---
  }

Beachten Sie, dass der firstValue genauso gezählt wird wie bei der SMA-Prozedur:

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;
//---
  }

as firstvalue = (x1 + x2 + x3 + ... + xn) / n

das ist die "grobe" Gleichung für den einfachen gleitenden Durchschnitt, aber nicht für den geglätteten gleitenden Durchschnitt

Vielleicht ist das der Grund für das Problem?

 

von dieser Website:

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

Der erste Wert für den geglätteten gleitenden Durchschnitt wird als einfacher gleitender Durchschnitt (SMA) berechnet:

SUM1=SUM (CLOSE, N)

SMMA1 = SUMME1/ N

Der zweite und die folgenden gleitenden Durchschnitte werden nach dieser Formel berechnet:

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

Wobei:

SUM1 - ist die Gesamtsumme der Schlusskurse für N Perioden;
SMMA1 - ist der geglättete gleitende Durchschnitt des ersten Balkens;
SMMA (i) - ist der geglättete gleitende Durchschnitt des aktuellen Balkens (mit Ausnahme des ersten Balkens);
CLOSE (i) - ist der aktuelle Schlusskurs;
N - ist die Glättungsperiode.

Ich vermute also, dass die iMa und die benutzerdefinierten gleitenden Durchschnitte dies auf die richtige Weise tun. Aber eine solche Berechnung führt zu den Fehlern, auf die wir gestoßen sind, was zu großen Unterschieden je nach den getesteten Zeiträumen führt. Das ist völlig inakzeptabel für einen EA, der seine Trades auf gleitenden Durchschnitten aufbaut. Ich schätze, ich werde Smoothed MA aus diesem Grund aus meinem EA entfernen müssen, da er beim Backtesting fehlerhafte Ergebnisse liefert. Selbst wenn ich es ab dem Jahr 2000 teste und es richtig hinbekomme, kann es sein, dass die Kunden es ab 2013 testen und sagen, dass es das Konto auslöscht", weil sie andere SSMA erhalten als ich.

Ein weiteres Zitat:
Der SMMA gewichtet die jüngsten Kurse gleich stark wie die historischen Kurse. Bei der Berechnung werden alle verfügbaren Datenreihen berücksichtigt, statt sich auf einen festen Zeitraum zu beziehen.

Deshalb ist es jedes Mal anders, wenn sich der Backtest-Zeitraum ändert.

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:

Bitte antworten Sie nicht innerhalb des Zitats. Wie Sie sehen, ist es jetzt leer, wenn ich Sie zitieren möchte.

Der Algorithmus ist gut für SMMA, irgendwo muss man ja anfangen. Aber Sie zeigen den Ursprung des Problems, wie SMMA ist auf den vorherigen Wert zu bauen, ist es empfindlich auf die Startbedingung. Da Sie auf einem Live-Chart und mit dem Strategietester nicht dieselbe Startkerze haben, erklärt das die unterschiedlichen Werte.

Das Gleiche gilt für den EMA, nach einer zweiten Überprüfung (auf D1) habe ich jetzt auch unterschiedliche Werte, wie beim SMMA.

 
angreeee:

von dieser Website:

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

Der erste Wert für den geglätteten gleitenden Durchschnitt wird wie ein einfacher gleitender Durchschnitt (SMA) berechnet:

SUM1=SUM (CLOSE, N)

SMMA1 = SUMME1/ N

Der zweite und die folgenden gleitenden Durchschnitte werden nach dieser Formel berechnet:

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

Wobei:

SUM1 - ist die Gesamtsumme der Schlusskurse für N Perioden;
SMMA1 - ist der geglättete gleitende Durchschnitt des ersten Balkens;
SMMA (i) - ist der geglättete gleitende Durchschnitt des aktuellen Balkens (mit Ausnahme des ersten Balkens);
CLOSE (i) - ist der aktuelle Schlusskurs;
N - ist die Glättungsperiode.

Ich vermute also, dass die iMa und die benutzerdefinierten gleitenden Durchschnitte dies auf die richtige Weise tun. Aber eine solche Berechnung führt zu den Fehlern, auf die wir gestoßen sind, was zu großen Unterschieden je nach den getesteten Zeiträumen führt. Das ist völlig inakzeptabel für einen EA, der seine Trades auf gleitenden Durchschnitten aufbaut. Ich schätze, ich werde Smoothed MA aus diesem Grund aus meinem EA entfernen müssen, da er beim Backtesting fehlerhafte Ergebnisse liefert. Selbst wenn ich es ab dem Jahr 2000 teste und es richtig hinbekomme, kann es sein, dass die Kunden es ab 2013 testen und sagen, dass es das Konto auslöscht", weil sie andere SSMA erhalten als ich.

Vielen Dank für den Link. Das bestätigt meinen vorherigen Beitrag. Das ist sehr interessant, da ich nie auf solche Dinge geachtet habe.

Wenn ich den Algorithmus des EMA überprüfe, ist er auch für dieses Problem empfindlich, ich weiß nicht, warum mein erster Test die gleichen Werte ergab.

1234
Neuer Kommentar