Анализ качества данных - страница 3

 
Urain >>:
.

А для защиты от запуска в int start() на каждом тике рекомендую такой фильтр:

код проверен и работает везде без глюков.



Теоретически - не везде. Вернее - не всегда. Самое надежное - сравнивать время текущего и пред. баров.

Но на практике и вариант с Bars надежен.

 
Svinozavr >>:

Самое надежное - сравнивать время текущего и пред. баров.

ага что-то вроде этого

static datetime lastbar;
int init()
{
   lastbar=Time[Bars-1];
}
int start()
{
   if (Time[0]>lastbar)
   {
      lastbar=Time[0];
      ...// работаем
   }
}
 
Mathemat >>:

Derrick, I'm truly amazed by the sort of data analysis you've done. What kind of ticks distribution function were you expecting? I mean which function is the ideal one?

Mathemat,

Thanks for replying. I certainly wasn’t expecting to observe any particular distribution of data but my analysis highlights some peculiarities that I cannot explain away using my knowledge of the market. With that, I am not suggesting anything other than obtaining deeper insight into the underlying mechanisms.

The most glaring feature is the complete absence of ticks on the last seconds of any minute. I may imagine some scenarios that can lead to data loss. However, in this analysis, the collected data spanned interval of an entire month (January ’08, historical data.) Therefore, there is certainly statistical significance to the observed pattern.

The other feature is the conspicuously large number of ticks on zeroth and 30th seconds with a rough ratio of 2:1 respectively.

Yet another point is the difference in the underlying data feeding expert adviser on different timeframes. In my understanding, by choosing a timeframe I select a way for the system to group underlying data. The bars will change but the ticks should remain the same except for the volume component of a tick. Volume on each tick will be incremented until a new bar is formed (and this is observed in collected data.) The timestamp on ticks should be the same. My query does not involve volume in any way. Therefore, if I run my query on data collected from two different timeframes, the distribution by second should be identical.

You may wonder why I find these findings significant. An expert adviser is triggered by an incoming tick. So if the system does not allocate any ticks for the last few seconds of every minute, your expert adviser will not work at that time. This may have implications for the design of your adviser. By the same token, your expert adviser will be triggered with a disproportionate frequency on zeroth and 30th seconds of every minute.

Perhaps these patterns are well known to you. If so, please direct me to the resources that you think explain them. If you feel comfortable, I can send you the design of the query. I cannot send the entire db due to size limitations. However, I do attach the mock expert adviser used for data export.

Respectfully,

Derrick

Файлы:
exporter.mq4  2 kb
 
alsu >>:

ага что-то вроде этого


Да просто замените бары на время:

datetime TimePrev; // или static в ф-ии 
int start()
{if(Time[0]!=TimePrev)
   {TimePrev=Time[0];
    //
    // запускаемый на каждом баре код
    //
   }
return(0);
}

Или, чтоб не увеличивать вложенность:

datetime TimePrev;
int start()
  {
   if(Time[0]==TimePrev) return(0);
   TimePrev=Time[0];
    //
    // запускаемый на каждом баре код
    //
   return(0);
  }
 
DerrickMeadows >>:

Mathemat,

Thanks for replying. I certainly wasn’t expecting to observe any particular distribution of data but my analysis highlights some peculiarities that I cannot explain away using my knowledge of the market. With that, I am not suggesting anything other than obtaining deeper insight into the underlying mechanisms.

The most glaring feature is the complete absence of ticks on the last seconds of any minute. I may imagine some scenarios that can lead to data loss. However, in this analysis, the collected data spanned interval of an entire month (January ’08, historical data.) Therefore, there is certainly statistical significance to the observed pattern.

The other feature is the conspicuously large number of ticks on zeroth and 30th seconds with a rough ratio of 2:1 respectively.

Yet another point is the difference in the underlying data feeding expert adviser on different timeframes. In my understanding, by choosing a timeframe I select a way for the system to group underlying data. The bars will change but the ticks should remain the same except for the volume component of a tick. Volume on each tick will be incremented until a new bar is formed (and this is observed in collected data.) The timestamp on ticks should be the same. My query does not involve volume in any way. Therefore, if I run my query on data collected from two different timeframes, the distribution by second should be identical.

You may wonder why I find these findings significant. An expert adviser is triggered by an incoming tick. So if the system does not allocate any ticks for the last few seconds of every minute, your expert adviser will not work at that time. This may have implications for the design of your adviser. By the same token, your expert adviser will be triggered with a disproportionate frequency on zeroth and 30th seconds of every minute.

Perhaps these patterns are well known to you. If so, please direct me to the resources that you think explain them. If you feel comfortable, I can send you the design of the query. I cannot send the entire db due to size limitations. However, I do attach the mock expert adviser used for data export.

Respectfully,

Derrick

It's quite strange to consider that loss of a single tick (even every minute as well) could affect strategy efficiency in a non-negligible way.

However, the first thing to mull over when such a problem arises should be dependence of your results on the data source. Have you explored the statistics with other data providers?

 
DerrickMeadows писал(а) >>

If you wish to have ideal data you should use eSignal. MT4 has no ideal data because server MT4 has a filtration of ticks. We do not know anything about this filtration of ticks.

 
Urain >>:

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

ТЕ прерывание потока данных если время бара вышло и открытие потока если начался новый бар. Именно поэтому на последней секунде бара никогда не бывает тика, он приходит уже на новом баре(иногда в виде гепа).

Urain, Вы можете объяснить, что означает "время бара вышло"? Формально, чисто теоретически, не существует точного времени окончания любого бара (если он еще не сформирован). А здесь получается так, что для минуток это 55-я секунда, а для 5-минуток - 59-я. Странно это как-то.

2 Derrick: thank you, I looked over your code, it's a simple collector of ticks. I have nothing to add to the replies of LeoV and maybe Urain.

P.S. It seems like the distribution function of ticks per second is far from uniform, at least for the 1- and 5-minute timeframes. Have you tried to do the same for H1 or higher timeframes?

 
Svinozavr >>:

Теоретически - не везде. Вернее - не всегда. Самое надежное - сравнивать время текущего и пред. баров.

Но на практике и вариант с Bars надежен.

В тестере вариант с Time не работает, вариант с Bars работает всегда(и в любой программе).

 
Mathemat >>:

Urain, Вы можете объяснить, что означает "время бара вышло"? Формально, чисто теоретически, не существует точного времени окончания любого бара (если он еще не сформирован). А здесь получается так, что для минуток это 55-я секунда, а для 5-минуток - 59-я. Странно это как-то.

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

А вижу я следующее: при сборе тиков, и отрисовке их значений в виде линии - сам график получается рваный,

и разрывы приходятся как раз на межбарный тик(это факты господа, их можно обьяснять по разному но с ними не поспориш).

У меня правда есть мысль по этому поводу, но предупреждаю сразу я не проверял: тики приходят когда есть изменение цены но не чаще чем Х мс.

Х=3500 мс.(взято приближенно). Таким образом ДЦ обеспечивают многозадачность своих серверов.

ТЕ чем реже ДЦ даёт котировку тем большее количество запросов можно обрабатывать теми же машинными ресурсами(соотношение цена/качество).

 
Urain >>:

и разрывы приходятся как раз на межбарный тик(это факты господа, их можно обьяснять по разному но с ними не поспориш).

а это не может быть артефактом какого нибудь алгоритма фильтрации котировок?
Причина обращения: