Tener un problema de media móvil cableada al crear EA.. - página 3

Nuevo comentario
 
angreeee:
Me di cuenta de nuevo, incluso cuando lo ejecuto desde 2009 en la fecha actual (04.2014) la diferencia entre el MA en el gráfico y el ima en backtest sigue siendo 0,10, así que supongo que el problema persiste. Voy a hacer mi propia función de reemplazo de iMa si todos los demás fallaron. icustom todavía devuelve sólo ceros en el gráfico D1, incluso cuando se inicia en 2009 y trabajando bien en el gráfico H4.
He confirmado antes que hay un problema con el modo SMMA, creo que ya lo has reportado al Service Desk. Otros modos parecen estar bien para mí.
 

Analizando el funcionamiento del indicador de media móvilpersonalizado entiendo por qué hay problemas de este tipo.

Cada media móvil es contada de manera no-cruda contando el siguiente frame de la media móvil a partir del frame anterior de la media móvil en lugar de sólo contar los frames necesarios (en este caso 370) para la ecuación. De esta manera, si una trama de la media móvil es incorrecta, todas las siguientes también lo serán. Cuanto más lejos de la trama de error, menor será el error. Incluso podría funcionar correctamente si todos los fotogramas desde el principio se contaran correctamente, pero me he dado cuenta de que a veces el iMA al principio informa de ceros (tengo un procedimiento para descartar las lecturas de ma defectuosas, pero el propio iMA no lo hace) y esos ceros probablemente también se tienen en cuenta al contar los siguientes fotogramas del iMA a partir de los fotogramas anteriores del iMA.
Por eso cuando empecé las pruebas retrospectivas en 2013 la diferencia era mayor, en 2012 era menor que al empezar en 2013, start=2011 aún menor, y así sucesivamente. La diferencia seguía siendo visible incluso cuando empecé la prueba retrospectiva de 2009, por lo que es un problema grave.

 
angevoyageur:
He confirmado antes que hay un problema con el modo SMMA, creo que ya lo has reportado al Servicio de Atención al Cliente. Los demás modos me parecen bien.

estoy terminando de escribir mi propio procedimiento de reemplazo de iMA para poder documentar y entender completamente el problema. (no sólo por comparación visual como se hace en este hilo).

Los resultados de ima, mi reemplazo de ima y los resultados de la media móvil personalizada estarán disponibles en el registro para su comparación.

P.D. Si confirmas el error, lo reportaré ahora. (añadiré un nuevo comentario en este hilo cuando el problema sea reportado). El sitio (o mi Internet) funciona muy lentamente en este momento, por lo que tengo problemas incluso para llegar a la página de servicio.
 
ok se informa.
 

Pensé que otros tipos de MA se ven afectados también, pero hice más pruebas y SSMA parece el único afectado, como usted ha dicho.

pero me di cuenta del problema de iCustom. Script para probar SSMA y iCustom cuestiones:

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

Analizando el funcionamiento del indicador de media móvil personalizado entiendo por qué hay problemas de este tipo.

Cada media móvil es contada de manera no-cruda contando el siguiente frame de la media móvil a partir del frame anterior de la media móvil en lugar de sólo contar los frames necesarios (en este caso 370) para la ecuación. De este modo, si una trama de la media móvil es incorrecta, todas las siguientes también lo serán. Cuanto más lejos de la trama de error, menor será el error. Incluso podría funcionar correctamente si todos los fotogramas desde el principio se contaran correctamente, pero me he dado cuenta de que a veces el iMA al principio informa de ceros (tengo un procedimiento para descartar las lecturas de ma defectuosas, pero el propio iMA no lo hace) y esos ceros probablemente también se tienen en cuenta al contar los siguientes fotogramas del iMA a partir de los fotogramas anteriores del iMA.
Por eso cuando empecé las pruebas retrospectivas en 2013 la diferencia era mayor, en 2012 era menor que al empezar en 2013, start=2011 aún menor, y así sucesivamente. La diferencia seguía siendo visible incluso cuando empecé la prueba retrospectiva de 2009, por lo que es un problema grave.

No veo el problema. iMA está bien codificado para el rendimiento. Si un iMA reporta un 0 es porque no tienes datos (o suficientes datos). Por cierto sólo hay un problema con SMMA, no sé por qué, pero no puede ser debido a esta implementación "incremental" ya que está funcionando bien para otro modo.
 
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.

Sí, tienes razón, sería mucho más lento. Pero el hecho es que esta forma de contar más algunos cuadros vacíos (ceros) al principio daría problemas como ese. (es por eso que iMA SSMA es siempre más pequeño, no más grande que el SSMA anual) Sé que no compruebo lo que iMA devuelve y por eso obtengo ceros al principio en lugar de manejar la falta de información necesaria adecuadamente, pero eso es un tema diferente.

Con TFs más pequeños hay muchos más frames analizados y el problema puede diluirse con el tiempo. Con cada nuevo frame la ima SSMA se acerca más y más a la SSMA real, así que cuantas más barras pasen, menos visible es el problema, por eso creo que nadie lo notó antes. El mismo problema encontré con 370 SSMA y PERIOD_12H PERIOD_8H, etc.

Si tienes tiempo por favor mira la función iCustom. Adjunto el código fuente para probarlo fácilmente. Compruebe cualquier TF inferior que PERIOD_D1 - iCustom funciona bien y devuelve los mismos valores que iMA. En PERIOD_D1 siempre son ceros para iCustom, mientras que iMA sigue reportando algunos valores.

Lo curioso es que cuando se usa SSMA en PERIOD_H12 máximo tanto iMA como el indicador "media móvil personalizada" de iCustom reportan valores defectuosos. (prueba desde 2014.01 para ver la diferencia)

El error tiene que estar en algún sitio: (formulario de media móvil personalizada)

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

Observe que el firstValue se cuenta igual que en el procedimiento 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;
//---
  }

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

que es la ecuación "cruda" para la media móvil simple, pero no para la media móvil suavizada

¿quizás sea esa la razón del problema?

 

de ese sitio:

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

El primer valor de la Media Móvil Suavizada se calcula como una Media Móvil Simple (SMA):

SUM1=SUMA (CIERRE, N)

SMMA1 = SUMA1/ N

La segunda y siguientes medias móviles se calculan según esta fórmula

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

Donde:

SUM1 - es la suma total de los precios de cierre de N períodos;
SMMA1 - es la media móvil suavizada de la primera barra;
SMMA (i) - es la media móvil suavizada de la barra actual (excepto la primera);
CLOSE (i) - es el precio de cierre actual;
N - es el periodo de suavización.

Así que supongo que el iMa y las medias móviles personalizadas lo hacen de forma correcta. Pero el cálculo así produce los errores como los que hemos encontrado resultando en enormes diferencias dependiendo de los períodos probados. Es totalmente inaceptable para un EA que basa sus operaciones en la media móvil. Supongo que tendré que eliminar la MA suavizada por esa razón de mi EA, ya que produce resultados defectuosos durante el backtesting. Incluso si lo prueban desde el año 2000 y lo hacen bien, los clientes pueden probarlo desde 2013 y decir que "borra la cuenta" porque obtendrán otras SSMA que yo.

Una cita más:
El SMMA da a los precios recientes la misma importancia que a los históricos. El cálculo tiene en cuenta todas las series de datos disponibles en lugar de referirse a un periodo fijo.

Por eso es diferente cada vez que cambia el periodo de back-test.

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:

Por favor, no respondas dentro de la cita. Como ves, cuando quiero citarte ahora está vacío.

El algoritmo es bueno para SMMA, tienes que empezar en algún lugar. Pero señalas el origen del problema, como el SMMA se construye sobre el valor anterior, es sensible a la condición de inicio. Como no tiene la misma vela de inicio en un gráfico en vivo y con el probador de la estrategia que explica los diferentes valores.

Lo mismo ocurre con la EMA, después de una segunda comprobación (en D1) ahora también tengo valores diferentes, como para la SMMA.

 
angreeee:

de ese sitio:

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

El primer valor de la Media Móvil Suavizada se calcula como una Media Móvil Simple (SMA):

SUM1=SUMA (CIERRE, N)

SMMA1 = SUMA1/ N

La segunda y siguientes medias móviles se calculan según esta fórmula

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

Donde:

SUM1 - es la suma total de los precios de cierre de N períodos;
SMMA1 - es la media móvil suavizada de la primera barra;
SMMA (i) - es la media móvil suavizada de la barra actual (excepto la primera);
CLOSE (i) - es el precio de cierre actual;
N - es el periodo de suavización.

Así que supongo que el iMa y las medias móviles personalizadas lo hacen de forma correcta. Pero el cálculo así produce los errores como los que hemos encontrado resultando en enormes diferencias dependiendo de los períodos probados. Es totalmente inaceptable para un EA que basa sus operaciones en la media móvil. Supongo que tendré que eliminar la MA suavizada por esa razón de mi EA, ya que produce resultados defectuosos durante el backtesting. Incluso si lo prueban desde el año 2000 y lo hacen bien, los clientes pueden probarlo desde 2013 y decir "se borra la cuenta" porque obtendrán otras SSMA que yo.

Gracias por el enlace. Eso confirma mi post anterior. Es muy interesante ya que nunca presto atención a estas cosas.

Comprobando el algoritmo de EMA también es sensible a este tema, no sé por qué mi primera prueba obtuvo los mismos valores.

1234
Nuevo comentario