Баг MQL5 при работе c доступом к таймсериям iClose/iOpen и т.д. - страница 9

 
Vitaly Muzichenko:

То есть, можно будет иметь очень быстрый индикатор с такой вот конструкцией?

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


Если это так, то это отличная новость!

 
Renat Fatkhullin:

У нас есть идея для индикаторов, которые не содержат флага #property tester_everytick_calculate, включать режим расчета на основе приема пачки тиков, а не на каждом тике.

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

Предлагаю другое решение.

SymbolInfoTick

Возвращает текущие цены  для указанного символа в переменной типа MqlTick.

bool  SymbolInfoTick( 
   string    symbol,     // символ 
   MqlTick&  tick        // ссылка на структуру
   bool      IndicatorMode = true; // индикаторный или реальный (текущий) тик
   );

Параметры

symbol

[in]  Имя символа.

tick

[out]  Ссылка на структуру типа MqlTick, в которую будут помещены текущие цены и время последнего обновления цен.

IndicatorMode

[out]  true - в индикаторах возвращает тик, который инициировал текущий NewCalculate, false - текущий (реального времени) тик символа.

Возвращаемое значение

Возвращает true в случае успеха, иначе false.


Тогда в OnCalculate достаточно будет прописать только такую конструкцию

// Возвращает true, если текущий и индикаторный тики совпадают
bool IsRealTick( void )
{
  MqlTick Tick1, Tick2;
  
  return(SymbolInfoTick(_Symbol, Tick1) && SymbolInfoTick(_Symbol, Tick2, false) && (Tick1.time_msc == Time2.time_msc));
}

int OnCalculate( ... )
{
  if (prev_calculated && !IsRealTick())
    return(prev_calculated); // Если тик устарел, идем к следующему
    
  // Body
  
  return(rates_total);
}

Такое решение видится более гибким и удобным и в плане использования и реализации.


ЗЫ Еще лучше было бы нумерация тиков, с возможностью получить номер текущего и индикаторного тика. Но такой вариант более сложный для разработчиков. Поэтому, наверное, не стоит.

 
fxsaber:

Предлагаю другое решение.

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

int OnCalculate( ... )
{
  static ulong MinTimeMsc = 0
  const ulong StartTime = GetMicrosecondCount();
  
  MqlTick Tick;
  const bool Res = prev_calculated && SymbolInfoTick(_Symbol, Tick);
  
  if (Res && (Tick.timeMsc < MinTimeMsc))
    return(prev_calculated); // Если тик устарел, идем к следующему
    
  // Body
  
  if (Res)
    MinTimeMsc = Tick.time_msc + (GetMicrosecondCount - StartTime) / 2000;
  
  return(rates_total);
}
 
fxsaber:

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

Ну вот не нужны тики посреди бара, все равно принудительно пропускаются. Давайте дождемся реализации от mql.

 
Unicornis:

Ну вот не нужны тики посреди бара, все равно принудительно пропускаются. Давайте дождемся реализации от mql.

Честно говоря, не понимаю, что мешало страждущим написать решение своей проблемы самим?

И почему разработчики должны здесь что-то менять?


Решение выше можно оформить в виде mqh-файла и одной строкой подключать к любому индикатору, как это, например, делается в Init_Sync. Но там хоть реально кода пришлось написать прилично и не очевидного. А здесь простые несколько строк.

Init_Sync
Init_Sync
  • www.mql5.com
Если в MT изменить таймфрейм или имя символа чарта, то все индикаторы на чарте выгрузятся с чарта и загрузятся на него снова. При этом, в отличие от MT4, в MT5 последовательность выгрузиться/загрузиться не определена из-за особенности внутренней архитектуры. Данное обстоятельство иногда вызывает не сразу очевидные проблемы, связанные с тем, что...
 
Renat Fatkhullin:

С заморозкой обновления чужого невидимого таймфрейма после реконнекта связи разобрались и исправили. Причина была в неправильных статусах кеша именно после реконнекта.

Бета версия 1946 доступна через Help -> Check Desktop Updates -> Latest Beta Version.

Ринат, 3 дня тестов проблем нет, спасибо!

 
fxsaber:

Честно говоря, не понимаю, что мешало страждущим написать решение своей проблемы самим?

И почему разработчики должны здесь что-то менять?

Страждущие никак не могут изменить количество приходящих тиков в индикатор, они их пропускают в индикаторе до нового бара, если индикатор долго считает, то тики все равно пропускаются. Под реалии как-то приходится подстраиваться.

Если для одного символа пиковое значение ~800 тиков в минуту, то для синтетика из нескольких символов уже 2300 тиков в минуту. Открыв один синтетик и один символ из него - пик  ~3000 тиков в минуту. Добавим еще другой таймфрейм того же синтетика и того же символа, и получаем... Хорошо, экранов Элдера было три, получаем пиково ~9000 тиков в минуту или 150 тиков в секунду. Ринат уже написал про вопросы производительности. Зачем пропускать через мультисимвольный-мтф индикатор холостые 150 тиков в секунду, если нужен 1-н тик в минуту для всех тф символа?  Аналогично,  в преимуществах хостинга mql указывается отсутствие накладных расходов со стороны хост системы, терминал это тот же хост только для индикаторов и экспертов. Если расчет индикатора состоит из RSI(3) + EMA(5)+ EMA(7), то конечно,  никакой проблемы в ближайшие 10 лет пока не предвидится.

В синтетиках(фактически мультисимвольный индикатор от терминала) Разработчики  как-то придумали слепливать несколько символов, зачем дублировать элементы этой системы(допустим даже не идеальной) на уровне рукоблудства программера в индикаторе?  Если систему можно упростить, то почему бы это не сделать. Когда еще земля стояла на трех слонах, 5-и секундный тф не просто так придумали.

Upd. Можно ввести тф 5 секунд без истории и на нем тики соответственно только раз в 5 секунд, а также оттестировать всякие решения(компиляция индикатора с каким нибудь префиксом для работы только на 5S, другие индикаторы на нем не будут запускаться) - существующая идеология терминала не трогается, поэтому можно будет менять и переиначивать решения, а лучшее/оптимальное решение в ходе тестирования образуется. 

(СУВЖ к Вашим разработкам библиотек, синтетикам, открепленным окнам и т.д. Разработчиков).

 
Unicornis:

Да хоть миллион тиков в минуту, от этого решение не рабочим не становится.

 
fxsaber:

Да хоть миллион тиков в минуту, от этого решение не рабочим не становится.

Вопрос не к рабочести решения. Целесообразность вызова индикатора на каждом дошедшем до него тике, перед которым неизвестное количество тиков было пропущено, к тому же рассматривается некое устаревание тика ??? Раз что то пропускается(с ростом нагрузки) и не известна актуальность пришедшего тика, то аналитическую задачу привязанную ко времени эта ситуация не решает - если нет, то зачем с этим заморачиваться.  Вообще запретить поток тиков в индикаторы, оставить тики в индикатор от платформы раз в 5 секунд - в минуту 12 тиков, этого достаточно.

 
Unicornis:

Вопрос не к рабочести решения. Целесообразность вызова индикатора на каждом дошедшем до него тике, перед которым неизвестное количество тиков было пропущено, к тому же рассматривается некое устаревание тика ??? Раз что то пропускается(с ростом нагрузки) и не известна актуальность пришедшего тика, то аналитическую задачу привязанную ко времени эта ситуация не решает - если нет, то зачем с этим заморачиваться.  Вообще запретить поток тиков в индикаторы, оставить тики в индикатор от платформы раз в 5 секунд - в минуту 12 тиков, этого достаточно.

Глупость.

Причина обращения: