Problème de moyenne mobile câblée lors de la création d'une EA... - page 3

Nouveau commentaire
 
angreeee:
J'ai remarqué à nouveau que même lorsque je l'exécute de 2009 à la date actuelle (04.2014), la différence entre la MA sur le graphique et l'ima dans le backtest est toujours de 0.10, donc je suppose que le problème persiste. Je vais faire ma propre fonction de remplacement de l'ima si toutes les autres ont échoué. icustom retourne toujours seulement des zéros sur le graphique D1 même en commençant à 2009 et fonctionne bien sur le graphique H4.
J'ai confirmé précédemment qu'il y a un problème avec le mode SMMA, je pense que vous l'avez déjà signalé au Service Desk ? Les autres modes me semblent corrects.
 

En analysant le fonctionnement de l'indicateur demoyenne mobile personnalisé, je comprends pourquoi il y a des problèmes comme celui-ci.

Chaque moyenne mobile est comptée de manière non brutale en comptant le cadre suivant de la moyenne mobile à partir du cadre précédent de la moyenne mobile au lieu de compter seulement les cadres nécessaires (dans ce cas 370) pour l'équation. De cette façon, si une image de la moyenne mobile est incorrecte, toutes celles qui suivent le seront également. Plus on s'éloigne de la trame d'erreur, plus l'erreur sera faible. Cela pourrait même fonctionner correctement si toutes les images depuis le début étaient comptées correctement, mais j'ai remarqué que parfois l'iMA au début rapporte des zéros (j'ai une procédure pour écarter les lectures ma défectueuses, mais l'iMA lui-même ne le fait pas) et ces zéros sont probablement aussi pris en considération lors du comptage des images suivantes de l'iMA à partir des images précédentes de l'iMA.
C'est pourquoi lorsque j'ai commencé les rétro-tests en 2013 la différence était la plus grande, en 2012 elle était plus petite que lorsque j'ai commencé en 2013, start=2011 encore plus petite, et ainsi de suite. La différence était encore visible même lorsque j'ai commencé à faire des rétro-tests à partir de 2009, il s'agit donc d'un problème sérieux.

 
angevoyageur:
J'ai confirmé précédemment qu'il y a un problème avec le mode SMMA, je pense que vous l'avez déjà signalé au Service Desk ? Les autres modes me semblent corrects.

Je finis d'écrire ma propre procédure de remplacement de l'IMA afin de pouvoir documenter et comprendre le problème. (pas seulement par comparaison visuelle comme dans ce fil).

Les résultats de l'ima, de mon remplacement de l'ima et des moyennes mobiles personnalisées seront disponibles dans le journal pour comparaison.

PS : si vous confirmez l'erreur, je la signale maintenant. (J'ajouterai un nouveau commentaire dans ce fil lorsque le problème sera signalé). Le site (ou mon internet) fonctionne très lentement en ce moment et j'ai même des problèmes pour accéder à la page du Service Desk.
 
ok c'est signalé.
 

Je pensais que d'autres types de MA étaient également affectés, mais j'ai fait d'autres tests et la SSMA semble être la seule affectée, comme vous l'avez dit.

Mais j'ai remarqué le problème iCustom. Script pour tester les problèmes de SSMA et 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();
}
Dossiers :
icustom_problem.png  143 kb
 
angreeee:

En analysant le fonctionnement de l'indicateur de moyenne mobile personnalisé, je comprends pourquoi il y a des problèmes comme celui-ci.

Chaque moyenne mobile est comptée de manière non brutale en comptant le cadre suivant de la moyenne mobile à partir du cadre précédent de la moyenne mobile au lieu de compter seulement les cadres nécessaires (dans ce cas 370) pour l'équation. De cette façon, si une image de la moyenne mobile est incorrecte, toutes celles qui suivent le seront également. Plus on s'éloigne de la trame d'erreur, plus l'erreur sera faible. Cela pourrait même fonctionner correctement si toutes les images depuis le début étaient comptées correctement, mais j'ai remarqué que parfois l'iMA au début rapporte des zéros (j'ai une procédure pour écarter les lectures ma défectueuses, mais l'iMA lui-même ne le fait pas) et ces zéros sont probablement aussi pris en considération lors du comptage des images suivantes de l'iMA à partir des images précédentes de l'iMA.
C'est pourquoi lorsque j'ai commencé les rétro-tests en 2013 la différence était la plus grande, en 2012 elle était plus petite que lorsque j'ai commencé en 2013, start=2011 encore plus petite, et ainsi de suite. La différence était encore visible même lorsque j'ai commencé à faire des rétro-tests à partir de 2009, il s'agit donc d'un problème sérieux.

Je ne vois pas le problème. iMA est bien codé pour la performance. Si un iMA rapporte un 0, c'est parce que vous n'avez pas de données (ou suffisamment de données). D'ailleurs, il n'y a de problème qu'avec SMMA, je ne sais pas pourquoi, mais cela ne peut pas être dû à cette implémentation "incrémentale" car cela fonctionne bien pour les autres modes.
 
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.

Oui, vous avez raison, ce serait beaucoup plus lent. Mais le fait est que cette façon de compter plus quelques images vides (zéros) au début résulterait en des problèmes comme celui-ci. (c'est pourquoi la SSMA d'iMA est toujours plus petite, pas plus grande que la SSMA réelle) Je sais que je ne vérifie pas ce que retourne iMA, c'est pourquoi j'obtiens des zéros au début au lieu de gérer correctement le manque d'informations nécessaires, mais c'est un autre problème.

Avec des TFs plus petites il y a beaucoup plus de trames analysées et le problème peut se diluer avec le temps. Avec chaque nouvelle image, la SSMA ima se rapproche de plus en plus de la SSMA réelle, donc plus il y a de barres passées, moins le problème est visible, c'est pourquoi je pense que personne ne l'a remarqué avant. J'ai trouvé le même problème avec la SSMA 370 et le PERIOD_12H PERIOD_8H, etc.

Si vous avez le temps, veuillez examiner la fonction iCustom. J'ai joint le code source pour le tester facilement. Vérifiez les TFs inférieurs que PERIOD_D1 - iCustom fonctionne bien et renvoie les mêmes valeurs que iMA. Dans PERIOD_D1 c'est toujours des zéros pour iCustom, alors que iMA rapporte toujours quelques valeurs.

Ce qui est curieux, c'est que lorsque vous utilisez SSMA sur PERIOD_H12 maximum, iMA et l'indicateur iCustom "moyenne mobile personnalisée" renvoient tous deux des valeurs erronées. (test à partir de 2014.01 pour voir la différence)

L'erreur doit se trouver quelque part ici : (formulaire moyenne mobile personnalisée)

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

Remarquez que la firstValue est comptée de la même manière que dans la procédure 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;
//---
  }

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

ce qui est l'équation "brute" pour la moyenne mobile simple, mais pas pour la moyenne mobile lissée.

Peut-être est-ce la raison de ce problème ?

 

de ce site :

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

La première valeur de la moyenne mobile lissée est calculée comme une moyenne mobile simple (SMA) :

SUM1=SUM (CLOSE, N)

SMMA1 = SUM1/ N

La deuxième moyenne mobile et les suivantes sont calculées selon cette formule :

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

Où :

SUM1 - est la somme totale des prix de clôture pour N périodes ;
SMMA1 - est la moyenne mobile lissée de la première barre ;
SMMA (i) - est la moyenne mobile lissée de la barre actuelle (sauf la première) ;
CLOSE (i) - est le prix de clôture actuel ;
N - est la période de lissage.

Je suppose donc que les iMa et les moyennes mobiles personnalisées le font de la bonne manière. Mais ce type de calcul produit des erreurs comme celles que nous avons rencontrées, entraînant d'énormes différences selon les périodes testées. C'est totalement inacceptable pour un EA qui base ses transactions sur des moyennes mobiles. Je pense que je vais devoir éliminer la MA lissée de mon EA pour cette raison, car elle produit des résultats erronés lors du backtesting. Même si je le teste à partir de l'année 2000 et que j'obtiens de bons résultats, les clients peuvent le tester à partir de 2013 et dire "cela efface le compte" parce qu'ils obtiendront d'autres SSMA que les miens.

Encore une citation :
La SMMA donne aux prix récents une pondération égale à celle des prix historiques. Le calcul prend en compte toutes les séries de données disponibles plutôt que de se référer à une période fixe.

C'est pourquoi elle est différente à chaque fois que la période de back-test change.

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:

S'il vous plaît, ne répondez pas à l'intérieur de la citation. Comme vous le voyez, quand je veux vous citer, c'est maintenant vide.

L'algorithme est bon pour le SMMA, il faut bien commencer quelque part. Mais vous pointez l'origine du problème, comme le SMMA est construit sur la valeur précédente, il est sensible à la condition de départ. Comme vous n'avez pas la même bougie de départ sur un graphique réel et avec le testeur de stratégie, cela explique les différentes valeurs.

Il en est de même pour l'EMA, après une deuxième vérification (sur D1) j'ai maintenant des valeurs différentes aussi, comme pour la SMMA.

 
angreeee:

de ce site :

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

La première valeur de la moyenne mobile lissée est calculée comme une moyenne mobile simple (SMA) :

SUM1=SUM (CLOSE, N)

SMMA1 = SUM1/ N

La deuxième moyenne mobile et les suivantes sont calculées selon cette formule :

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

Où :

SUM1 - est la somme totale des prix de clôture pour N périodes ;
SMMA1 - est la moyenne mobile lissée de la première barre ;
SMMA (i) - est la moyenne mobile lissée de la barre actuelle (sauf la première) ;
CLOSE (i) - est le prix de clôture actuel ;
N - est la période de lissage.

Donc je suppose que l'iMa et les moyennes mobiles personnalisées le font de la bonne manière. Mais ce type de calcul produit des erreurs comme celles que nous avons rencontrées, entraînant d'énormes différences selon les périodes testées. C'est totalement inacceptable pour un EA qui base ses transactions sur la moyenne mobile. Je pense que je vais devoir éliminer la MA lissée de mon EA pour cette raison, car elle produit des résultats erronés lors du backtesting. Même si je le teste à partir de l'année 2000 et que j'obtiens de bons résultats, les clients peuvent le tester à partir de 2013 et dire "cela efface le compte" parce qu'ils obtiendront d'autres SSMA que les miens.

Merci pour le lien. Cela confirme mon message précédent. C'est très intéressant car je ne fais jamais attention à ce genre de choses.

En vérifiant l'algorithme de l'EMA, il est également sensible à ce problème, je ne sais pas pourquoi mon premier test a obtenu les mêmes valeurs.

1234
Nouveau commentaire