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

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

Можно попытаться определить.

Если это минутки, то можно сравнить время последнего бара с TimeCurrent(). Если не M1, то можно спросить iTime(_Symbol,PERIOD_M1,0) и сравнить с TimeCurrent().

Можно сравнить цену Bid или Last (в зависимости от инструмента) с ценой Close последнего бара. Можно сразу спросить SymbolInfoTick текущего символа. Там кроме бида и ласта ещё и время тика еть

благодарю, хоть какая информация появилась где и как искать баги если что то пошло не так

но думаю, что все равно нужна встроенная функция по проверке состояния или еще лучше это был бы флаг как int _LastError в которой бы хранилось количество пропущенных тиков, было бы удобно при вызове OnCalculate() - при сложных расчетах делать сразу return, чтобы освободить поток символа

 
Igor Makanu:

благодарю, хоть какая информация появилась где и как искать баги если что то пошло не так

но думаю, что все равно нужна встроенная функция по проверке состояния или еще лучше это был бы флаг как int _LastError в которой бы хранилось количество пропущенных тиков, было бы удобно при вызове OnCalculate() - при сложных расчетах делать сразу return, чтобы освободить поток символа

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

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

а всяческие проверки тиков в индикаторе на предмет их актуальности - это мягко говоря не выход.

 

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

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

 
Renat Fatkhullin:

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

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

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

//+-------------------------------------------+
int OnInit() 
  {
  EventSetMillisecondTimer(200);
//-
  return(INIT_SUCCEEDED);
 }

//+-------------------------------------------+
int OnCalculate (const int rates_total,
                 const int prev_calculated,
                 const datetime& time[],
                 const double& open[],
                 const double& high[],
                 const double& low[],
                 const double& close[],
                 const long& tick_volume[],
                 const long& volume[],
                 const int& spread[])
 {
  // Здесь ничего не делаем, нам не нужен в данном случае OnCalculate
  return(rates_total);
 }

//+-------------------------------------------+
void OnTimer()
 {
  // Здесь расчёты, и вывод информации на график в виде графических объектов
 }

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

 
Renat Fatkhullin:

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

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

Отличная новость, очень ждём, надеемся... а если сделаете стандартную функцию для получения синхронизированого мультивалютного массива, то вообще будет праздник

 
Renat Fatkhullin:

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

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

Хорошая идея! 

И желательно, чтобы это работало без всяких #property по умолчанию.

Если кому надо иначе, тогда пусть ставят #property.

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

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

 
_o0O:
Приём тиков пачками - это хорошее и, наверное, малокровное решение, если не нужен реалтайм (непонятно правда, как смогут работать советники с такими индикаторами, которые работают по "вчерашним" ценам, ну да ладно).

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

БОльшая доля советников по индикаторам работает с закрытым баром[1], поэтому пропуски тиков не имеют значения, это актуально для индикаторов работающих с тиками, но таких не много, им как раз и можно выделить "#property tester_everytick_calculate"

И опять-же, если нужны супер-тики, то для этого не нужен индикатор, всё это можно написать в коде советника. Так что тормозить всю работу индикатора ради каждого тика - не рационально.

Ждём "#property tester_everytick_calculate"

 
Vitaly Muzichenko:

БОльшая доля советников по индикаторам работает с закрытым баром[1], поэтому пропуски тиков не имеют значения, это актуально для индикаторов работающих с тиками, но таких не много, им как раз и можно выделить "#property tester_everytick_calculate"

И опять-же, если нужны супер-тики, то для этого не нужен индикатор, всё это можно написать в коде советника. Так что тормозить всю работу индикатора ради каждого тика - не рационально.

Ждём "#property tester_everytick_calculate"


Ок, и как сказанное Вами не согласуется с моими словами?
 
Может кому-то будет полезно. У меня мультивалютный индикатор,  так  вот основные емкостные расчеты я делаю в блоке инициализации и только отрисовку в онкалькулейт.  Правда это выход для ситуаций когда сами линии индикатора не содержат сложных вычислений.  В моем случае это портфельный индикатор отображающий график поведения портфеля. 
12345678910
Новый комментарий