Ночью обратил внимание на одну очень странную вещь, время начала бара отрабатывается с ошибкой – ошибка была больше минуты. Сейчас решил проверить, создал проверочный индикатор
#property indicator_chart_windowdatetime old_time=0;
int MaxBars=10; // ограничение //+------------------------------------------------------------------+//| Custom indicator initialization function |//+------------------------------------------------------------------+intOnInit() {return(0);}
//+------------------------------------------------------------------+//| Custom indicator iteration function |//+------------------------------------------------------------------+intOnCalculate(constint rates_total,
constint prev_calculated,
constdatetime& time[],
constdouble& open[],
constdouble& high[],
constdouble& low[],
constdouble& close[],
constlong& tick_volume[],
constlong& volume[],
constint& spread[])
{
if(rates_total<10) return(0); // ничего не считаем и ничего не рисуем на графике int start_pos, // точка старта
count_tick;
MqlDateTime str1,str2;
if(prev_calculated==0)
{
old_time=0;
count_tick=0;
start_pos=rates_total-3;
}
else start_pos=prev_calculated-1;
//--- расчет for(int i=start_pos;i<rates_total;i++)
{
TimeToStruct(TimeCurrent(),str1); // время сервераTimeToStruct(time[i], str2); // время бара if(str1.min!=str2.min) {
// Сбой - тик принадлежит не своему бару
count_tick++;
Print("тик №=",count_tick," i=", i," c=",close[i]," time[i]=",time[i]," time=",TimeCurrent()," delta=",str1.sec);
}
} // end for(...return(rates_total);
}
Первые два тика понятны, это запуск индикатора. А вот следующие …. Получается что по серверному времени уже давно идет новый бар, а этот тик принадлежит старому бару. Ночью эта дельта вообще кошмар…
Вопрос к разработчикам это баг ? или так и было задумано ?
Ночью обратил внимание на одну очень странную вещь, время начала бара отрабатывается с ошибкой – ошибка была больше минуты. Сейчас решил проверить, создал проверочный индикатор
Если вы добавите в вывод значение rates_total, то вы увидите, что ошибки возникают, когда вы сравниваете минуты текущие с минутами предыдущего бара.
Параметры open[], high[], low[] и close[] содержит массивы с ценами открытия, максимальной, минимальной ценами и ценами закрытия текущего таймфрейма. Параметр time[] содержит массив со значениями времени открытия, параметр spread[] – массив, содержащий историю спредов (если спред предусмотрен для данного торгового инструмента). Параметры volume[] и tick_volume[] содержат соответственно историю торгового и тикового объема.
Ночью обратил внимание на одну очень странную вещь, время начала бара отрабатывается с ошибкой – ошибка была больше минуты. Сейчас решил проверить, создал проверочный индикатор
Первые два тика понятны, это запуск индикатора. А вот следующие …. Получается что по серверному времени уже давно идет новый бар, а этот тик принадлежит старому бару. Ночью эта дельта вообще кошмар…
Вопрос к разработчикам это баг ? или так и было задумано ?
Попробуйте проверить следующим образом. Без цикла.
Далее по тексту.
упс понял. спасибо. я внутри цикла делал проверку
if(old_time<time[i])
{
Print("НОВЫЙ бар");
old_time=time[i];
//...
}
// а нужно вот такif(old_time<time[rates_total-1]) // работаем только по завершенным барам
{
Print("НОВЫЙ бар");
old_time=time[rates_total-1];
//...
}
В момент появления нового бара i не поменялось. Не экономно, происходит повторный расчет одних и тех же данных. Хотя...
вот такая ситуация https://book.mql4.com/ru/samples/icustom рис.119 исключна в MQL5 если нет ? и вот такой шаблон индикатора всегда выдаст правильное close ? или есть подводные камни ?
inputint MaxBars=240;
datetime old_time=0;
//+------------------------------------------------------------------+//| Custom indicator initialization function |//+------------------------------------------------------------------+intOnInit() {return(0);}
//+------------------------------------------------------------------+//| Custom indicator iteration function |//+------------------------------------------------------------------+intOnCalculate(constint rates_total,
constint prev_calculated,
constdatetime& time[],
constdouble& open[],
constdouble& high[],
constdouble& low[],
constdouble& close[],
constlong& tick_volume[],
constlong& volume[],
constint& spread[])
{
//---if(prev_calculated==0)
{
//... расчитать историю//...
old_time=time[rates_total-1];
}
// работаем только по завершенным барамif(old_time<time[rates_total-1])
{
old_time=time[rates_total-1];
Print("НОВЫЙ бар close[1]=",close[rates_total-2]);
}
//--- return value of prev_calculated for next callreturn(rates_total);
}
sergey1294: у меня тоже какая-то чертовщина с тестером твориться, начинаю запускать своего советника, в тестере вылетает весь терминал, если кидаю его на график, то все в норме. другие советники нормально работают в тестере.
Опытным путем получено и доказано, что гарантированно перевариться может примерно 110 параметров (и то есть вопросы). При 120 уже вылетает терминал, если советник указан в тестере.
Некоторые пути решения я уже давал в личке, но если что, то можно еще и к разработчикам с этим вопросом обратиться. Я думаю они должны помочь в вопросе обхода этого ограничения...
Опытным путем получено и доказано, что гарантированно перевариться может примерно 110 параметров (и то есть вопросы). При 120 уже вылетает терминал, если советник указан в тестере.
Некоторые пути решения я уже давал в личке, но если что, то можно еще и к разработчикам с этим вопросом обратиться. Я думаю они должны помочь в вопросе обхода этого ограничения...
странно конечно, что такое ограничение действует на тестер. В четверке например нет такой проблемы
Опытным путем получено и доказано, что гарантированно перевариться может примерно 110 параметров (и то есть вопросы). При 120 уже вылетает терминал, если советник указан в тестере.
Некоторые пути решения я уже давал в личке, но если что, то можно еще и к разработчикам с этим вопросом обратиться. Я думаю они должны помочь в вопросе обхода этого ограничения...
stringo: Можно оптимизировать не более 64 параметров.
Оптимизировать 64, а юзать в тестере примерно 110 (без оптимизации). Хотя 110 это конечно само по себе уже "кошмарное" число параметров для эксперта (но бывает и такое)...
Ночью обратил внимание на одну очень странную вещь, время начала бара отрабатывается с ошибкой – ошибка была больше минуты. Сейчас решил проверить, создал проверочный индикатор
Лог2010.06.18 10:42:03 prov_tick (EURUSD,M1) тик №=6 i=50558 c=1.23797 time[i]=2010.06.18 08:41:00 time=2010.06.18 08:42:05 delta=5
2010.06.18 10:40:59 prov_tick (EURUSD,M1) тик №=5 i=50557 c=1.23848 time[i]=2010.06.18 08:40:00 time=2010.06.18 08:41:01 delta=1
2010.06.18 10:40:01 prov_tick (EURUSD,M1) тик №=4 i=50556 c=1.23862 time[i]=2010.06.18 08:39:00 time=2010.06.18 08:40:04 delta=4
2010.06.18 10:39:03 prov_tick (EURUSD,M1) тик №=3 i=50555 c=1.23881 time[i]=2010.06.18 08:38:00 time=2010.06.18 08:39:05 delta=5
2010.06.18 10:38:30 prov_tick (EURUSD,M1) тик №=2 i=50554 c=1.23859 time[i]=2010.06.18 08:37:00 time=2010.06.18 08:38:31 delta=31
2010.06.18 10:38:30 prov_tick (EURUSD,M1) тик №=1 i=50553 c=1.23858 time[i]=2010.06.18 08:36:00 time=2010.06.18 08:38:31 delta=31
Первые два тика понятны, это запуск индикатора. А вот следующие …. Получается что по серверному времени уже давно идет новый бар, а этот тик принадлежит старому бару. Ночью эта дельта вообще кошмар…
Вопрос к разработчикам это баг ? или так и было задумано ?
З.Ы. пока писал вот что в логе
2010.06.18 10:45:09 prov_tick (EURUSD,M1) тик №=9 i=50561 c=1.23787 time[i]=2010.06.18 08:44:00 time=2010.06.18 08:45:12 delta=12
Ночью обратил внимание на одну очень странную вещь, время начала бара отрабатывается с ошибкой – ошибка была больше минуты. Сейчас решил проверить, создал проверочный индикатор
Если вы добавите в вывод значение rates_total, то вы увидите, что ошибки возникают, когда вы сравниваете минуты текущие с минутами предыдущего бара.
То есть time[rates_total-2].
Кроме того не совсем понятен вывод дельты.
https://www.mql5.com/ru/docs/basis/function/events#oncalculate сказано:
Параметры open[], high[], low[] и close[] содержит массивы с ценами открытия, максимальной, минимальной ценами и ценами закрытия текущего таймфрейма. Параметр time[] содержит массив со значениями времени открытия, параметр spread[] – массив, содержащий историю спредов (если спред предусмотрен для данного торгового инструмента). Параметры volume[] и tick_volume[] содержат соответственно историю торгового и тикового объема.
Ночью обратил внимание на одну очень странную вещь, время начала бара отрабатывается с ошибкой – ошибка была больше минуты. Сейчас решил проверить, создал проверочный индикатор
Лог2010.06.18 10:42:03 prov_tick (EURUSD,M1) тик №=6 i=50558 c=1.23797 time[i]=2010.06.18 08:41:00 time=2010.06.18 08:42:05 delta=5
2010.06.18 10:40:59 prov_tick (EURUSD,M1) тик №=5 i=50557 c=1.23848 time[i]=2010.06.18 08:40:00 time=2010.06.18 08:41:01 delta=1
2010.06.18 10:40:01 prov_tick (EURUSD,M1) тик №=4 i=50556 c=1.23862 time[i]=2010.06.18 08:39:00 time=2010.06.18 08:40:04 delta=4
2010.06.18 10:39:03 prov_tick (EURUSD,M1) тик №=3 i=50555 c=1.23881 time[i]=2010.06.18 08:38:00 time=2010.06.18 08:39:05 delta=5
2010.06.18 10:38:30 prov_tick (EURUSD,M1) тик №=2 i=50554 c=1.23859 time[i]=2010.06.18 08:37:00 time=2010.06.18 08:38:31 delta=31
2010.06.18 10:38:30 prov_tick (EURUSD,M1) тик №=1 i=50553 c=1.23858 time[i]=2010.06.18 08:36:00 time=2010.06.18 08:38:31 delta=31
Первые два тика понятны, это запуск индикатора. А вот следующие …. Получается что по серверному времени уже давно идет новый бар, а этот тик принадлежит старому бару. Ночью эта дельта вообще кошмар…
Вопрос к разработчикам это баг ? или так и было задумано ?
З.Ы. пока писал вот что в логе
2010.06.18 10:45:09 prov_tick (EURUSD,M1) тик №=9 i=50561 c=1.23787 time[i]=2010.06.18 08:44:00 time=2010.06.18 08:45:12 delta=12
Попробуйте проверить следующим образом. Без цикла.
Далее по тексту.
Попробуйте проверить следующим образом. Без цикла.
Далее по тексту.
упс понял. спасибо. я внутри цикла делал проверку
В момент появления нового бара i не поменялось. Не экономно, происходит повторный расчет одних и тех же данных. Хотя...
вот такая ситуация https://book.mql4.com/ru/samples/icustom рис.119 исключна в MQL5 если нет ? и вот такой шаблон индикатора всегда выдаст правильное close ? или есть подводные камни ?
З.Ы. спасибо за наукуу меня тоже какая-то чертовщина с тестером твориться, начинаю запускать своего советника, в тестере вылетает весь терминал, если кидаю его на график, то все в норме. другие советники нормально работают в тестере.
Опытным путем получено и доказано, что гарантированно перевариться может примерно 110 параметров (и то есть вопросы). При 120 уже вылетает терминал, если советник указан в тестере.
Некоторые пути решения я уже давал в личке, но если что, то можно еще и к разработчикам с этим вопросом обратиться. Я думаю они должны помочь в вопросе обхода этого ограничения...
Опытным путем получено и доказано, что гарантированно перевариться может примерно 110 параметров (и то есть вопросы). При 120 уже вылетает терминал, если советник указан в тестере.
Некоторые пути решения я уже давал в личке, но если что, то можно еще и к разработчикам с этим вопросом обратиться. Я думаю они должны помочь в вопросе обхода этого ограничения...
сейчас выходные котировки не идут. запускаю скрипт
Print(TimeCurrent());
результат
2010.06.20 00:26:06 00 (USDJPY,M1) 2010.06.18 22:35:52
хотя последний бар имеет время 2010.06.18 23:00:00
как то странно, очень неудобно тестировать правильность работы некоторых функций.
Не хватает кнопки "Применить" в окне настроек индикатора.
Опытным путем получено и доказано, что гарантированно перевариться может примерно 110 параметров (и то есть вопросы). При 120 уже вылетает терминал, если советник указан в тестере.
Некоторые пути решения я уже давал в личке, но если что, то можно еще и к разработчикам с этим вопросом обратиться. Я думаю они должны помочь в вопросе обхода этого ограничения...
Можно оптимизировать не более 64 параметров.