Рациональные приемы (предложения) ускорения оптимизатора - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Как по мне, то объект исследования не должен управлять экспериментом над самим собой.
Много сэкономить удалось-то?
Результаты зависят от ТС, конечно. Через кастомную историю удавалось значительно повысить точность тестирования, скорость же увеличивалась в разы. К сожалению, не все можно решить через кастомную историю. Поэтому и предложил доп. функцию.
Для ускорения оптимизации можно не пользоваться встроенным тестером а написать свой на основе массивов-таймсерий. Правда торговые функции в тестируемом коде нужно будет заменить на иной способ подсчета прибылей(убытков). Для ТС торгующим по средам результаты должны быть близкими, а время работы написанного тестера-оптимизатора должно быть в 5 раз меньше(т.к считаются только среды) штатного тестера.
Да, алгоритмических оптимизаций может быть множество. Специально избегаю их в теме. Речь пока только об очень простых и логичных способах ускорения имеющихся тестеров.
В общем, хочется более рационального использования бэктестинга.
Замените OnTick на OnTimer, и настраивайте следующее его срабатывание на нужную дату. Это позволит пропустить множество вызовов OnTick.
Если в исследуемом промежутке нужно все-таки работать по тикам, оставьте ОнТик, но давайте ему работать только по семафору.
Но я опять (недавно была похожая тема) склоняюсь к мнению, что проблема высосана из пальца.
Вы не могли бы показать пример оптимизационной задачи, которая не влазит в разумные временные рамки?
И, опять же, что мешает для решения конкретной задачи задействовать клауд (если это не постоянные переоптимизации, конечно)?
Замените OnTick на OnTimer, и настраивайте следующее его срабатывание на нужную дату. Это позволит пропустить множество вызовов OnTick.
Если в исследуемом промежутке нужно все-таки работать по тикам, оставьте ОнТик, но давайте ему работать только по семафору.
Этот вариант, но другими словами, в первом посте был предложен сразу. Речь идет о рациональном использовании вычислительных ресурсов. Для чего вызывать миллионы раз в каждом проходе OnTick с проверкой на семафор, если заведомо известно о полной ненужности такого действия?
Но я опять (недавно была похожая тема) склоняюсь к мнению, что проблема высосана из пальца.
Вы не могли бы показать пример оптимизационной задачи, которая не влазит в разумные временные рамки?
И, опять же, что мешает для решения конкретной задачи задействовать клауд (если это не постоянные переоптимизации, конечно)?
Понимаете, можно умножение реализовать в виде сложения. Для кого-то такая реализация не покажется медленной. Но давайте все же находиться в пределах разумного - эффективно с точки зрения производительности писать код. И постараться не делать лишних вычислений. Именно это и предлагаю.
Для чего, например, на каждом проходе вычислять тот же коэффициент Шарпа и прочие ненужности во время оптимизационного процесса? Подход "хочешь ускорения - рапрараллеливай или покупай более сильное железо" довольно распространенный сейчас, но какая-то в нем беспечность. Может, занудствую не по делу. Поэтому и задал вопрос изначально про целесообразность функционала для гибкой алгоритмической оптимизации.
Этот вариант, но другими словами, в первом посте был предложен сразу. Речь идет о рациональном использовании вычислительных ресурсов. Для чего вызывать миллионы раз в каждом проходе OnTick с проверкой на семафор, если заведомо известно о полной ненужности такого действия?
Я предложил задействовать ОнТаймер и "планировать" его следующий вызов "на следующую среду". Вы бы хоть попробовали сначала (и поделились результатами сравнения)...
Занудство к месту, если действительно есть массовая проблема. И если действительно есть простое и действенное решение.
Пока похоже, что предлагается решить проблему 1% пользователей, вложив достаточно много ресурсов.
OnTimer имеет смысл использовать в данном случае, если OnTick отсутствует напрочь. Но это не всегда возможно. Более того, если присутствует только OnTimer, то тики не пропускаются до следующего OnTimer, как могло бы подуматься. Т.е. цикл for i++ продолжает вхолостую молотить.
Да и тему про лишние вычисления стат. показателей на каждом оптимизационном прогоне как-то забывают. Короче, не настаиваю. Вижу возможности улучшения, требущие минимум усилий от разработчиков.
Замените OnTick на OnTimer, и настраивайте следующее его срабатывание на нужную дату. Это позволит пропустить множество вызовов OnTick.
Если в исследуемом промежутке нужно все-таки работать по тикам, оставьте ОнТик, но давайте ему работать только по семафору.
В тестере MQL4 OnTimer не поддерживается. В тестере MQL5 поддерживается но если в коде содержится функция OnTick она ( OnTick) всё равно будет вызываться каждый тик.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
komposter:
"Я предложил задействовать ОнТаймер и "планировать" его следующий вызов "на следующую среду". Вы бы хоть попробовали сначала (и поделились результатами сравнения)."..
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
T.k разрешается только один таймер для каждого кода, разрешите задать Вам как опытному программисту вопросы : Как торговать по средам в тестере стратегий используя только OnTimer без OnTick ?
Открывать и закрывать ордера с наступлением каждой среды? И всё ?
---------------------------------------------------------------------------------------------------------------------------------------------------
komposter:
Вы не могли бы показать пример оптимизационной задачи, которая не влазит в разумные временные рамки?
---------------------------------------------------------------------------------------------------------------------------------------------------
Оптимизация кода содержащего циклы переборки, сортировки пользовательских массивов и переборки массивов-таймсерий уходящих вглубь истории более чем на 512 баров.
Если код совершает сделки редко(1 сделка в 2-3 дня и реже) можно ускорить тестирование вручную. Например. Когда код открыл ордер тестирование прекращается. Bычисляется дата бара при котором произойдет срабатывание TP или SL. Настраивается тестирование начиная с этой даты бара со вводом тикета ордера.
Не совсем понимаю подоплеку Ваших переживаний. Огромное количество MQL-возможностей использует менее процента пользователей. Более того, ввод предложенной элементарной функции никаких серьезных человеко-затрат не требует. Минимум усилий нужно для замены в цикле for по тикам i++ на i += NextStep.
OnTimer имеет смысл использовать в данном случае, если OnTick отсутствует напрочь. Но это не всегда возможно. Более того, если присутствует только OnTimer, то тики не пропускаются до следующего OnTimer, как могло бы подуматься. Т.е. цикл for i++ продолжает вхолостую молотить.
Да и тему про лишние вычисления стат. показателей на каждом оптимизационном прогоне как-то забывают. Короче, не настаиваю. Вижу возможности улучшения, требущие минимум усилий от разработчиков.
Не все так просто. Если бы было += Степ, сделали бы уже давно.
И я все равно не понимаю - что мешает проверить скорость предложенного мной варианта? Сколько реально съедает вызов пустого ОнТика (с одной проверкой, без позиций)?
T.k разрешается только один таймер для каждого кода, разрешите задать Вам как опытному программисту вопросы : Как торговать по средам в тестере стратегий используя только OnTimer без OnTick ?
Открывать и закрывать ордера с наступлением каждой среды? И всё ?
Таймер можно удалять и запускать новый, с новым интервалом.
Оптимизация кода содержащего циклы переборки, сортировки пользовательских массивов и переборки массивов-таймсерий уходящих вглубь истории более чем на 512 баров.
Если код совершает сделки редко(1 сделка в 2-3 дня и реже) можно ускорить тестирование вручную. Например. Когда код открыл ордер тестирование прекращается. Bычисляется дата бара при котором произойдет срабатывание TP или SL. Настраивается тестирование начиная с этой даты бара со вводом тикета ордера.
Я просил реальную задачу. Придумать я и сам гаразд )
Да и натыкался в своих изысках на такие задачи, естественно. Но каждый раз находил какое-то решение, редко было действительно нужно молотить кучу вариантов на огромной истории.
В тестере MQL4 OnTimer не поддерживается. В тестере MQL5 поддерживается но если в коде содержится функция OnTick она ( OnTick) всё равно будет вызываться каждый тик.
Я в 4-ке с таймером в тестере не работал. Если это так, то надо как минимум в пятерке проверкить.
Неужели не интересно?
1.Таймер можно удалять и запускать новый, с новым интервалом.
2. Я просил реальную задачу. Придумать я и сам гаразд )
Да и натыкался в своих изысках на такие задачи, естественно. Но каждый раз находил какое-то решение, редко было действительно нужно молотить кучу вариантов на огромной истории.
Я в 4-ке с таймером в тестере не работал. Если это так, то надо как минимум в пятерке проверкить.
Неужели не интересно?
1. В справке написано "Рекомендуется вызывать функцию EventSetTimer() однократно в функции OnInit(), а функцию EventKillм Timer() вызывать однократно в OnDeinit()."
2. Если Вы имеете ввиду конкретный код то пожалуйста. Торговая стратегия поиска разворотов на основе кода Popular_Prices.https://www.mql5.com/ru/code/12310 В код вставил торговые функции и подсчет объёмов. На каждом баре происходит переборка пяти массивов-таймсерий, переборка,сортировка пользовательских массивов. Ввел несколько параметров оптимизация которых идет долго. Если найдете на меня время- подробности напишу в личку.