Новая версия платформы MetaTrader 5 build 2360: Расширение интеграции с SQLite - страница 51
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
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!
Бревно со вчерашнего и сегодняшнего дня: / 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 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
Случалось на разных торговых серверах. Если нужно, могу в личку их скинуть, но толку, наверное, ноль.
Два Терминала на одной и той же машине подключены к одному торговому серверу. Один - висит, второй - нормально.В MQL есть TerminalClose(), для Python есть возможность подключаться к торговым счетам через login/password/server.
Возможно ли в ближайших билдах добавить в MQL TerminalRelogin()?
есть целая группа проблем, которая ещё с четвёрки тянется: запуск советника/индикатора до того как запустился график/терминал. обнаруживается на запуске терминала, но далеко не всегда. периодически возвращает разного рода ошибки.
прошу либо запретить это на уровне терминала, либо дать переменную-флаг (или функцию), которую эксперт может прочитать. я одно время пытался вставлять разные проверки, но каждый раз натыкался на что-то новое... в итоге решил, что все параметры перебрать придётся.
сегодняшнее:
из 31 графика 3 не запустились:
в этой строке:
ширина графика в пикселях.
примечательно, что эти три графика идут подряд, но где-то в середине списка
с этим тэмплэйтом я терминал уже не раз запускал. для эксперимента закрыл/открыл терминал - не повторилось.
из примеров, то что на память приходит (что так же может дать подобный сбой), значение пункта равное нулю, цена тика, размер аккаунта, количество глобальных переменных... из характеристик графиков помню только цвет заднего фона сбоил (но это в четвёрке ещё было)... ну и теперь вот ширина добавилась...
есть целая группа проблем, которая ещё с четвёрки тянется: запуск советника/индикатора до того как запустился график/терминал. обнаруживается на запуске терминала, но далеко не всегда. периодически возвращает разного рода ошибки.
прошу либо запретить это на уровне терминала, либо дать переменную-флаг (или функцию), которую эксперт может прочитать. я одно время пытался вставлять разные проверки, но каждый раз натыкался на что-то новое... в итоге решил, что все параметры перебрать придётся.
сегодняшнее:
из 31 графика 3 не запустились:
в этой строке:
ширина графика в пикселях.
примечательно, что эти три графика идут подряд, но где-то в середине списка
с этим тэмплэйтом я терминал уже не раз запускал. для эксперимента закрыл/открыл терминал - не повторилось.
из примеров, то что на память приходит (что так же может дать подобный сбой), значение пункта равное нулю, цена тика, размер аккаунта, количество глобальных переменных... из характеристик графиков помню только цвет заднего фона сбоил (но это в четвёрке ещё было)... ну и теперь вот ширина добавилась...
Зачем это делать в OnInit() ?
Зачем это делать в OnInit() ?
в последнем примере отступ делается чтоб график не перекрывал панель инструментов. установка отступа продублирована в OnChartEvent(), но при первом запуске, пока не было события изменения графика - как определить отступ? не делать же проверки на каждом тике или по какому-то ещё событию, не имеющему отношения к изменению графика?
я видел (и сам такое вставлял в свои коды) взведение флага типа
но это как раз костыль, который подпирает кривую инициализацию. это же тоже своего рода инициализация. то, что должно быть сделано один раз при запуске.
Заметьте, описанные выше проблемы никогда не вылезают в тестере!
то что должно быть сделано один раз при запуске, должно корректно работать в OnInit()
в последнем примере отступ делается чтоб график не перекрывал панель инструментов. установка отступа продублирована в OnChartEvent(), но при первом запуске, пока не было события изменения графика - как определить отступ? не делать же проверки на каждом тике или по какому-то ещё событию, не имеющему отношения к изменению графика?
я видел (и сам такое вставлял в свои коды) взведение флага типа
но это как раз костыль, который подпирает кривую инициализацию. это же тоже своего рода инициализация. то, что должно быть сделано один раз при запуске.
Заметьте, описанные выше проблемы никогда не вылезают в тестере!
то что должно быть сделано один раз при запуске, должно корректно работать в OnInit()
Делайте в OnInit(). Но делайте проверку на нулевые значения там, где их быть по логике вещей не должно. И если они есть там, где их быть не должно - взводите флаг, и по этому флагу в OnTick() или OnCalculate() делайте нужный расчёт - опять же с проверкой нулевого значения. Если опять нулевое - выход до следующего тика.
Что уж есть. Но ошибок критических избежите, и работать будет в любых ситуациях неготовности данных в OnInit().
Делайте в OnInit(). Но делайте проверку на нулевые значения там, где их быть по логике вещей не должно. И если они есть там, где их быть не должно - взводите флаг, и по этому флагу в OnTick() или OnCalculate() делайте нужный расчёт - опять же с проверкой нулевого значения. Если опять нулевое - выход до следующего тика.
Что уж есть. Но ошибок критических избежите, и работать будет в любых ситуациях неготовности данных в OnInit().
спасибо за поддержку и признание проблемы! ;) но даже если я сделаю проверку на "не ноль", откуда мне знать, что этот "не ноль" истинный, а не просто мусорное значение?
Например, упомянутое выше CHART_WIDTH_IN_PIXELS при неактивном, но развёрнутом графике выдаёт значение свёрнутого (не так давно целая ветка была с примерами). другой пример (правда ещё с четвёрки) - перелогинил аккаунт, а _Point и/или AccountBallance() не успели обновиться...
как раз с того и начал - никогда не знаешь, какие значения будут не готовы в следующий раз. вот тот пример, который я сегодня привёл работает с прошлого года в той или иной форме (я имею ввиду узел с отступом чарта). а вот сегодня - сбойнул :(
потому и прошу решить проблему в корне, а не в костыле.
спасибо за поддержку и признание проблемы! ;)
он как раз и не признал проблемы, а поддержал разработчика, который не обеспечил заявленный функционал:
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
это так на вскидку )))
Что уж есть.
ага... историй много, Ваша почему то из разряда: "а еще можно в этой машине порвавшийся ремень генератора дамскими чулками на время заменить! НО МАШИНА ТО ОГО-ГО! - ХОРОШАЯ!"
Проверяйте все делители.
При таком стиле написания у вас много где проблемы будут.
Проверяйте все делители.
При таком стиле написания у вас много где проблемы будут.
почему нельзя реализовать событие OnInit() для MQL-программ?
если это событие, то терминал должен организовать рассылку этих событий, когда готово виртуальное окружение, проблема возникает же именно при запуске терминала с открытыми чартами и запущенными MQL-программами
как сейчас реализован OnInit() - это, имхо, точка входа, а не событие
ЗЫ: а все примеры из справки корректны? - там везде есть проверки? да и что делать если вот в OnInit() получил вместо свойств чарта значение 0 ? - выйти из OnInit() с результатом INIT_FAILED ? и ? любой пользователь не поймет почему написанный во фриалнсе ЕА после перезагрузки терминала вместо того, чтобы "дежурить", взял да просто "вылетел" ;)