Новая версия платформы MetaTrader 5 build 2360: Расширение интеграции с SQLite - страница 51

 

I (Win 7.64, b.2418) включил 12-е и последнее ядро для чисто локальной оптимизации (12 ядер, ожидаемая продолжительность ~ 33 часа) вечером. Утром я ждал, пока статус одного из ядер не изменится со значения% на "готово". Через некоторое время все они изменились на «готово» и остались там - никакой дальнейшей оптимизации не произошло - первое разочарование.

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

С одной стороны, кэш используется на дисплее, а журнал тестера не показывает никаких новых лучших значений после запуска, но кэш не используется для оптимизации или продолжения на основе того, что уже достигнуто - это очень жаль!
К сожалению, нет интеллектуального поведения, когда одно или несколько ядер отключены на локальном ПК. Оптимизация просто кажется остановилась. Очень грустный!

I (Win 7.64, b.2418) had enabled the 12th and last core for a purely local optimization (12 cores, expected duration ~33h) in the evening. In the morning I waited until the status of one of the cores changed from a % value to "ready". After some time they all changed to "finished" and stayed there - no further optimization took place - first disappointment.

So I stopped the whole optimization and started it again without changing any of the inputs. I was looking forward to it, but too early. The previous results were only apparently taken over by showing them in the result table and as data points in the result graphic, but the optimization does not take over one of the results to continue the optimization from the last state. This can be recognized by the fact that the results in the table start again at the beginning around zero and not in the areas of the optimization that have already been reached.

On the one hand, the cache is used in the display and the tester's journal does not show any new best values after the start, but the cache is not used for the optimization or for the continuation on the basis of what has already been achieved - that is a great pity!
Unfortunately, there is no intelligent behavior when one or more cores are switched off on the local PC. The optimization just seems to stop. Very sad!


After Restart


Бревно со вчерашнего и сегодняшнего дня: / The log from yesterday and today:

// log of Fr. 2020 05 15
NN    0    22:53:05.324    Core 12    agent process started on 127.0.0.1:3011
DI    0    22:53:06.045    Core 12    connecting to 127.0.0.1:3011
LH    0    22:53:06.045    Core 12    connected
LN    0    22:53:06.057    Core 12    authorized (agent build 2418)
PJ    0    22:53:06.073    Core 12    common synchronization completed

// log of Sa. 2020 05 16
KQ    0    00:03:40.580    Tester    Best result 2893.012184708425 produced at generation 0. Next generation 1
LE    0    00:47:09.648    Tester    Best result 2893.012184708425 produced at generation 0. Next generation 2
IH    0    01:30:01.841    Tester    Best result 3105.650142991749 produced at generation 2. Next generation 3
EL    0    02:13:37.818    Tester    Best result 3105.650142991749 produced at generation 2. Next generation 4
RS    0    02:56:05.219    Tester    Best result 3249.727766471291 produced at generation 4. Next generation 5
GG    0    03:39:27.222    Tester    Best result 3249.727766471291 produced at generation 4. Next generation 6
NJ    0    04:20:28.325    Tester    Best result 3249.727766471291 produced at generation 4. Next generation 7
EN    0    05:01:33.525    Tester    Best result 3636.666168733387 produced at generation 7. Next generation 8
JM    0    05:39:28.481    Tester    Best result 3958.118647448683 produced at generation 8. Next generation 9
DQ    0    06:17:41.375    Tester    Best result 5072.91812940309 produced at generation 9. Next generation 10
CD    0    06:57:31.293    Tester    Best result 5249.600690406681 produced at generation 10. Next generation 11
IK    0    07:33:03.552    Tester    Best result 5271.26600852332 produced at generation 11. Next generation 12
GL    0    08:06:54.839    Core 09    connection closed
RF    0    08:07:25.853    Core 12    connection closed
HQ    0    08:11:02.414    Tester    result cache used 257 times
OF    0    08:11:02.414    Tester    genetic optimization finished on pass 3583
DO    0    08:11:02.414    Statistics    optimization done in 9 hours 37 minutes 59 seconds
EJ    0    08:11:02.414    Statistics    shortest pass 0:01:11.383, longest pass 0:04:06.511, average pass 0:02:01.226
EF    0    08:11:02.414    Statistics    local 3326 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)
LP    0    08:11:02.417    Tester    3316 new records saved to cache file 'tester\cache\Drift v18.USDJPY.H4.20100110.20200502.11.ECB89E945A8E3DCD3F07648F010C6155.opt'
FJ    0    08:11:02.417    Core 01    connection closed
DG    0    08:11:02.418    Core 02    connection closed
MQ    0    08:11:02.418    Core 03    connection closed
NK    0    08:11:02.418    Core 04    connection closed
CD    0    08:11:02.418    Core 05    connection closed
PN    0    08:11:02.418    Core 06    connection closed
IK    0    08:11:02.418    Core 07    connection closed
RE    0    08:11:02.418    Core 08    connection closed
OO    0    08:11:02.418    Core 10    connection closed
EH    0    08:11:02.419    Core 11    connection closed
IM    3    08:11:02.419    Tester    stopped by user
HQ    0    08:11:03.842    Tester    cache file 'tester\cache\Drift v18.USDJPY.H4.20100110.20200502.11.ECB89E945A8E3DCD3F07648F010C6155.opt' contains 3316 records
HG    0    08:11:03.842    Tester    Experts\Drift v18.ex5 on USDJPY,H4 from 2010.01.10 00:00 to 2020.05.02 00:00
OO    0    08:11:03.842    Tester    genetic optimization started
MJ    0    08:11:03.842    Tester    reading of 3316 result records from cache...
RM    0    08:11:03.843    Tester    1 blocks of results read from cache in 0 ms
RG    0    08:11:03.853    Core 01    connecting to 127.0.0.1:3000
PL    0    08:11:03.853    Core 02    connecting to 127.0.0.1:3001
JK    0    08:11:03.853    Core 01    connected
HQ    0    08:11:03.853    Core 03    connecting to 127.0.0.1:3002
FN    0    08:11:03.853    Core 04    connecting to 127.0.0.1:3003
QI    0    08:11:03.853    Core 02    connected
NR    0    08:11:03.853    Core 05    connecting to 127.0.0.1:3004
LK    0    08:11:03.853    Core 06    connecting to 127.0.0.1:3005
DN    0    08:11:03.853    Core 03    connected
DL    0    08:11:03.853    Core 07    connecting to 127.0.0.1:3006
RE    0    08:11:03.853    Core 08    connecting to 127.0.0.1:3007
PL    0    08:11:03.853    Core 05    connected
DG    0    08:11:03.854    Core 08    connected
HJ    0    08:11:03.854    Core 06    connected
MN    0    08:11:03.854    Core 07    connected
FQ    0    08:11:03.854    Core 04    connected
LI    0    08:11:03.860    Core 06    authorized (agent build 2418)
QP    0    08:11:03.860    Core 03    authorized (agent build 2418)
QK    0    08:11:03.860    Core 05    authorized (agent build 2418)
DR    0    08:11:03.860    Core 08    authorized (agent build 2418)
HM    0    08:11:03.860    Core 02    authorized (agent build 2418)
FD    0    08:11:03.861    Core 07    authorized (agent build 2418)
CO    0    08:11:03.862    Core 01    authorized (agent build 2418)
IF    0    08:11:03.863    Core 04    authorized (agent build 2418)
PR    0    08:11:03.874    Core 09    agent process started on 127.0.0.1:3008
HE    0    08:11:03.874    Core 10    connecting to 127.0.0.1:3009
GL    0    08:11:03.874    Core 10    connected
MI    0    08:11:03.874    Core 11    connecting to 127.0.0.1:3010
FH    0    08:11:03.874    Core 11    connected
MQ    0    08:11:03.881    Core 11    authorized (agent build 2418)
PH    0    08:11:03.881    Core 10    authorized (agent build 2418)
NP    0    08:11:03.884    Core 04    common synchronization completed
CH    0    08:11:03.885    Core 06    common synchronization completed
GQ    0    08:11:03.887    Core 08    common synchronization completed
NI    0    08:11:03.889    Core 01    common synchronization completed
OF    0    08:11:03.891    Core 07    common synchronization completed
CN    0    08:11:03.891    Core 03    common synchronization completed
OG    0    08:11:03.894    Core 02    common synchronization completed
QO    0    08:11:03.899    Core 05    common synchronization completed
FD    0    08:11:03.901    Core 11    common synchronization completed
RL    0    08:11:03.904    Core 10    common synchronization completed
LE    0    08:11:04.346    Core 09    connecting to 127.0.0.1:3008
LL    0    08:11:04.346    Core 09    connected
GJ    0    08:11:04.355    Core 09    authorized (agent build 2418)
DF    0    08:11:04.365    Core 09    common synchronization completed

Исправление: также лучшие значения начинаются снова с 0 :(

Correction: also the best values start again at 0 :(

2020.05.16 08:11:04.346    Core 09    connecting to 127.0.0.1:3008
2020.05.16 08:11:04.346    Core 09    connected
2020.05.16 08:11:04.355    Core 09    authorized (agent build 2418)
2020.05.16 08:11:04.365    Core 09    common synchronization completed
2020.05.16 09:47:12.597    Tester    Best result 1127.809238933338 produced at generation 0. Next generation 1
2020.05.16 10:33:00.353    Tester    Best result 1127.809238933338 produced at generation 0. Next generation 2
2020.05.16 11:17:39.035    Tester    Best result 2083.455530035661 produced at generation 2. Next generation 3


 
fxsaber:

Случалось на разных торговых серверах. Если нужно, могу в личку их скинуть, но толку, наверное, ноль.

Два Терминала на одной и той же машине подключены к одному торговому серверу. Один - висит, второй - нормально.

В MQL есть TerminalClose(), для Python есть возможность подключаться к торговым счетам через login/password/server.

Возможно ли в ближайших билдах добавить в MQL TerminalRelogin()?

 

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

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

сегодняшнее:

из 31 графика 3 не запустились:

в этой строке:

ширина графика в пикселях.

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

с этим тэмплэйтом я терминал уже не раз запускал. для эксперимента закрыл/открыл терминал - не повторилось.

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

 
Igor Zakharov:

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

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

сегодняшнее:

из 31 графика 3 не запустились:

в этой строке:

ширина графика в пикселях.

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

с этим тэмплэйтом я терминал уже не раз запускал. для эксперимента закрыл/открыл терминал - не повторилось.

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

Зачем это делать в OnInit() ?

 
Artyom Trishkin:

Зачем это делать в OnInit() ?

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

я видел (и сам такое вставлял в свои коды) взведение флага типа

bool first_start=true;
...

void OnTick()
{
 if(first_start)
  {
   .....
   first_start=false;
  }
}

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

Заметьте, описанные выше проблемы никогда не вылезают в тестере!

то что должно быть сделано один раз при запуске, должно корректно работать в OnInit()

 
Igor Zakharov:

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

я видел (и сам такое вставлял в свои коды) взведение флага типа

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

Заметьте, описанные выше проблемы никогда не вылезают в тестере!

то что должно быть сделано один раз при запуске, должно корректно работать в OnInit()

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

Что уж есть. Но ошибок критических избежите, и работать будет в любых ситуациях неготовности данных в OnInit().

 
Artyom Trishkin:

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

Что уж есть. Но ошибок критических избежите, и работать будет в любых ситуациях неготовности данных в OnInit().

спасибо за поддержку и признание проблемы! ;) но даже если я сделаю проверку на "не ноль", откуда мне знать, что этот "не ноль" истинный, а не просто мусорное значение?

Например, упомянутое выше CHART_WIDTH_IN_PIXELS при неактивном, но развёрнутом графике выдаёт значение свёрнутого (не так давно целая ветка была с примерами). другой пример (правда ещё с четвёрки) - перелогинил аккаунт, а _Point и/или AccountBallance() не успели обновиться...

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

потому и прошу решить проблему в корне, а не в костыле.

 
Igor Zakharov:

спасибо за поддержку и признание проблемы! ;) 

он как раз и не признал проблемы, а поддержал разработчика, который не обеспечил заявленный функционал:

 https://www.mql5.com/ru/docs/event_handlers/oninit

https://www.mql5.com/ru/docs/runtime/event_fire#init

Вы конкретно обозначили область применения - инициализация свойств чарта, что полностью соответствует рекомендуемым примерам из документации от разработчика  - у Вас в секции OnInit() происходит обращение к свойствам чарта

https://www.mql5.com/ru/docs/chart_operations


это так на вскидку )))

Artyom Trishkin:

Что уж есть. 

ага... историй много, Ваша почему то из разряда: "а еще можно в этой машине порвавшийся ремень генератора дамскими чулками на время заменить! НО МАШИНА ТО ОГО-ГО! - ХОРОШАЯ!"

 

Проверяйте все делители.

При таком стиле написания у вас много где проблемы будут.

 
Renat Fatkhullin:

Проверяйте все делители.

При таком стиле написания у вас много где проблемы будут.

почему нельзя реализовать событие OnInit() для MQL-программ? 

если это событие, то терминал должен организовать рассылку этих событий, когда готово виртуальное окружение, проблема возникает же именно при запуске терминала с открытыми чартами и запущенными MQL-программами

как сейчас реализован OnInit() - это, имхо, точка входа, а не событие


ЗЫ: а все примеры из справки корректны? - там везде есть проверки? да и что делать если вот в OnInit() получил вместо свойств чарта значение 0 ? - выйти из OnInit() с результатом INIT_FAILED ?  и ? любой пользователь не поймет почему написанный во фриалнсе ЕА после перезагрузки терминала вместо того, чтобы "дежурить", взял да просто "вылетел" ;)

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