Насколько долгим может быть start()?

Новый комментарий
 
Скажем - задумывается советник с такой характерной чертой: при первом(и только первом) вызове start() начинается реально долгий обсчет исторических данных. При последующих вызовах эти данные просто используются, это быстро, а вот первый запуск запросто может выкатить к 10-20 мин. пока start() вернет управление. Ясно, что при этом изрядное кол-во тиков будет пропущено - это ОК. Но ОК ли это с т.з. самого терминала? Не считает ли последний, что если start() не вернул управление за 3 мин.(условно), то он завис и его следует грохнуть? Или терминалу все едино, и start() может и час управление не возвращать?
 

Терминалу всё едино. У мну есть несколько советников, в которых start() не возвращает управление неделями.

 

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

 

Терминалу всё едино. У мну есть несколько советников, в которых start() не возвращает управление неделями

Прикольно. :) Торгует на реале, надеюсь? :)))) И спасибо за ответ!

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

А вот тут, между прочим, не все так однозначно... По удобству реализации место такой дооооолгой процедуре - 100% в init, а не в start. НО! На сколько я знаю в init-е не гарантируется готовность данных по инструменту/котировкам. Т.е. - можем мы в init забить все элементы строкового массива строкой "JustString"? Абсолютно точно можем - нам от рынка ничего не надо. А можем мы в нем же узнать о размере минимального лота через MarketInfo()? Или цену High 2 бара назад? Скорей всего нет - данные не готовы. А на первом тике start-а - готовы!

Я вижу ситуацию вот так. Если не прав - старшие товарищи, верю, меня поправят. Ну или одобрительно кивнут в случае моей правоты. :)

 
scorpionk писал (а) >>

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

логичней подготовку сделать например на Делфи или Си++

быстро и мгновенно

зачем мучать MQL :-) у него другие плюсики



---

а Игорь, скорее говорит о зацикленных экспертах :-)


они входят в старт на первом тике :-) ночью в понедельник и уже не выходят из старта ... неделями :-) до глубокой ночи пятницы

в выходные комп или выключается или делаются оптимизации

 

SamMan писал (а) >>


На сколько я знаю в init-е не гарантируется готовность данных по инструменту/котировкам.

На эту тему Ренат отвечал в одном из постов, что негарантированность имеет место только в индикаторах, а в экспертах init() гарантирует достоверность окружения.

Если я не прав поправьте, пожалуйста!

 
VBAG писал (а) >>

На эту тему Ренат отвечал в одном из постов, что негарантированность имеет место только в индикаторах, а в экспертах init() гарантирует достоверность окружения.

Если я не прав поправьте, пожалуйста!

MarketInfo гарантируется. Наличие всех исторических данных - нет.

 
stringo писал (а) >>

MarketInfo гарантируется. Наличие всех исторических данных - нет.

Спасибо за уточнение.

Тогда сам по себе напрашивается вопрос: А ограничен ли по времени init()?

А если нет, то тогда неверное возможно в нем разместить собственные функции подгрузки данных и таким образом получить гарантию наличия исторических данных?

 
SamMan писал (а) >>
Прикольно. :) Торгует на реале, надеюсь? :)))) И спасибо за ответ!

Да, на реале... на нескольких счетах... замкнутый цикл... код такой:

while (IsExpertEnabled() && !IsStopped()) {
  // тело советника
  Sleep(1000*pause);
}
 
У меня еще один похожий вопрос: индикатор типа зигзаг. Мне нет необходимости пересчитывать каждый бар на истории, только от текущего последнего до начального. И если после долгой паузы в работе при запуске программы я открываю терминал, то иногда создается впечатление что индикатор принимает правильные данные по нулевому бару, а терминал еще не отрисовал этот бар и присваивает эти данные текущему последнему бару на экране. Из-за чего виден сбой. При перескоке с таймфрейма туда-обратно все ОК. Поэтому вопрос: как получить подтверждение что на окне отрисовались все бары? И только тогда начать пересчет.
 
wellx писал (а) >>
У меня еще один похожий вопрос: индикатор типа зигзаг. Мне нет необходимости пересчитывать каждый бар на истории, только от текущего последнего до начального. И если после долгой паузы в работе при запуске программы я открываю терминал, то иногда создается впечатление что индикатор принимает правильные данные по нулевому бару, а терминал еще не отрисовал этот бар и присваивает эти данные текущему последнему бару на экране. Из-за чего виден сбой. При перескоке с таймфрейма туда-обратно все ОК. Поэтому вопрос: как получить подтверждение что на окне отрисовались все бары? И только тогда начать пересчет.

Если произошла подкачка истории, то функция IndicatorCounted() вернет нулевое значение. Отсюда и пляшите.

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