Проблема с проводным скользящим средним при создании советника... - страница 3

Новый комментарий
 
angreeee:
Я снова заметил, что даже когда я запускаю его с 2009 года на текущую дату (04.2014), разница между MA на графике и ima в бэктесте по-прежнему составляет 0.10, так что я думаю, что проблема сохраняется. Я сделаю свою собственную функцию замены iMa, если все остальные не сработают. icustom по-прежнему возвращает только нули на графике D1, даже если начать с 2009 года, и работает нормально на графике H4.
Я подтвердил ранее, что есть проблема с режимом SMMA, я думаю, вы уже сообщили об этом в Service Desk? Другие режимы, как мне кажется, в порядке.
 

Анализируя, как работаетпользовательский индикаторскользящих средних, я понимаю, почему возникают подобные проблемы.

Каждая скользящая средняя рассчитывается не грубым способом, считая следующий фрейм скользящей средней от предыдущего фрейма скользящей средней, а не просто считая необходимые (в данном случае 370) фреймы для уравнения. Таким образом, если 1 фрейм MA ошибочен, то все последующие тоже будут ошибочными. Чем дальше от кадра ошибки, тем меньше будет ошибка. Это могло бы даже работать правильно, если бы все кадры от начала были подсчитаны правильно, но я заметил, что иногда iMA при старте сообщает нули (у меня есть процедура отбрасывания ошибочных показаний ma, но сам iMA этого не делает) и эти нули, вероятно, также учитываются при подсчете следующих кадров iMA от предыдущих кадров iMA.
Поэтому, когда я начал бэк-тесты в 2013 году, разница была наибольшей, в 2012 она была меньше, чем при старте в 2013, start=2011 еще меньше, и так далее. Разница все еще была заметна, даже когда я начал бэктест с 2009 года, так что это серьезная проблема.

 
angevoyageur:
Я подтвердил ранее, что есть проблема с режимом SMMA, я думаю, вы уже сообщили об этом в Service Desk? Другие режимы, как мне кажется, в порядке.

я заканчиваю писать свою собственную процедуру замены iMA, чтобы полностью задокументировать и понять проблему. (не просто визуальное сравнение, как это сделано в этой теме).

Результаты ima, моей замены ima и результаты пользовательской скользящей средней будут доступны в журнале для сравнения.

PS. если вы подтвердите ошибку, я сообщу о ней сейчас. (я добавлю новый комментарий в этой теме, когда о проблеме будет сообщено). Сайт (или мой интернет) работает очень медленно в данный момент, поэтому у меня проблемы даже с доступом к странице службы технической поддержки.
 
Хорошо, об этом сообщено.
 

Я думал, что другие типы 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) фреймы для уравнения. Таким образом, если 1 кадр MA ошибочен, то все последующие тоже будут ошибочными. Чем дальше от кадра ошибки, тем меньше будет ошибка. Это могло бы даже работать правильно, если бы все кадры от начала были подсчитаны правильно, но я заметил, что иногда iMA при старте сообщает нули (у меня есть процедура отбрасывания ошибочных показаний ma, но сам iMA этого не делает) и эти нули, вероятно, также учитываются при подсчете следующих кадров 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.

Да, вы правы, это было бы намного медленнее. Но дело в том, что такой способ подсчета плюс несколько пустых кадров (нулей) в начале приведет к подобным проблемам. (вот почему SSMA iMA всегда меньше, а не больше, чем обычный SSMA) Я знаю, что не проверяю, что возвращает iMA, поэтому я получаю нули в начале, вместо того, чтобы правильно обработать отсутствие необходимой информации, но это другой вопрос.

На маленьких ТФ анализируется гораздо больше фреймов, и проблема может быть размыта со временем. С каждым новым фреймом има SSMA становится все ближе и ближе к реальной SSMA, поэтому чем больше баров проходит, тем менее заметна проблема, вот почему я думаю, что никто не заметил ее раньше. Такую же проблему я обнаружил с 370 SSMA и PERIOD_12H PERIOD_8H и т.д.

Если у вас есть время, пожалуйста, посмотрите на функцию iCustom. Я приложил исходный код, чтобы легко протестировать ее. Проверьте все нижние ТФ, которые PERIOD_D1 - iCustom работает нормально и возвращает те же значения, что и iMA. В 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;
//---
  }

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

что является "грубым" уравнением для простой скользящей средней, но не для сглаженной скользящей средней.

Может быть, в этом причина проблемы?

 

с этого сайта:

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

Первое значение для сглаженной скользящей средней рассчитывается как простая скользящая средняя (SMA):

SUM1=SUM (CLOSE, N)

SMMA1 = SUM1/ N

Второе и последующие скользящие средние рассчитываются по следующей формуле:

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

Где:

SUM1 - общая сумма цен закрытия за N периодов;
SMMA1 - сглаженное скользящее среднее первого бара;
SMMA (i) - сглаженное скользящее среднее текущего бара (кроме первого);
CLOSE (i) - текущая цена закрытия;
N - период сглаживания.

Таким образом, я полагаю, что iMa и пользовательские скользящие средние делают это правильно. Но подобные расчеты приводят к ошибкам, с которыми мы столкнулись, что приводит к огромным различиям в зависимости от тестируемых периодов. Это совершенно неприемлемо для советника, который строит свои сделки на основе скользящих средних. Полагаю, что мне придется исключить Smoothed MA по этой причине из моего советника, поскольку он дает ошибочные результаты при бэктестинге. Даже если я протестирую его в 2000 году и получу правильные результаты, клиенты могут протестировать его в 2013 году и сказать "он уничтожает счет", потому что они получат другие SSMA, чем я.

Еще одна цитата:
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

Первое значение для сглаженной скользящей средней рассчитывается как простая скользящая средняя (SMA):

SUM1=SUM (CLOSE, N)

SMMA1 = SUM1/ N

Вторая и последующие скользящие средние рассчитываются по следующей формуле:

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

Где:

SUM1 - общая сумма цен закрытия за N периодов;
SMMA1 - сглаженное скользящее среднее первого бара;
SMMA (i) - сглаженное скользящее среднее текущего бара (кроме первого);
CLOSE (i) - текущая цена закрытия;
N - период сглаживания.

Таким образом, я полагаю, что iMa и пользовательские скользящие средние делают это правильно. Но подобные расчеты приводят к ошибкам, с которыми мы столкнулись, что приводит к огромным различиям в зависимости от тестируемых периодов. Это совершенно неприемлемо для советника, который строит свои сделки на основе скользящих средних. Полагаю, что мне придется исключить Smoothed MA по этой причине из моего советника, поскольку он дает ошибочные результаты при бэктестинге. Даже если я протестирую его в 2000 году и получу правильные результаты, клиенты могут протестировать его в 2013 году и сказать "он уничтожает счет", потому что они получат другие SSMA, чем я.

Спасибо за ссылку. Это подтверждает мой предыдущий пост. Это очень интересно, поскольку я никогда не обращал внимания на такие вещи.

Проверив алгоритм EMA, можно сказать, что он также чувствителен к такому вопросу, не знаю, почему мой первый тест дал такие же значения.

1234
Новый комментарий