Отключение оптимизации параметров в зависимости от input переменной.
- www.mql5.com
Да, с фреймами разбирался. Не понятно как это можно использовать в данном случае. Если я гоню только со включенным модулем или только с выключенным - в таком случае можно включать и выключать параметры автоматически на OnTesterInit. Если оптимизация идет с и без модуля - такое не представляется возможным.
Да, с фреймами разбирался. Не понятно как это можно использовать в данном случае. Если я гоню только со включенным модулем или только с выключенным - в таком случае можно включать и выключать параметры автоматически на OnTesterInit. Если оптимизация идет с и без модуля - такое не представляется возможным.
Рашид, скорее всего, предлагал обратить внимание на функцию ParameterSetRange. Там можно включать/отключать параметры от оптимизации.
- www.mql5.com
Рашид, скорее всего, предлагал обратить внимание на функцию ParameterSetRange. Там можно включать/отключать параметры от оптимизации.
Включить отключить можно и при настройке параметров. Впопрос в том, как их отключить в в зависимости от конкретного параметра, который так же меняется во время оптимизации.
Включить отключить можно и при настройке параметров. Впопрос в том, как их отключить в в зависимости от конкретного параметра, который так же меняется во время оптимизации.
А внутри самого эксперта это сделать нельзя?
Скажем, есть параметр, который может принимать значения от 1 до 100. Но, при этом надо исключить значения 10-20, 50-60 и 80-90.
Отлично. Вводим искусственный параметр, который может принимать значения от 1 до 70, Первые 10 значений таких же, как и в "настоящем параметре", далее 30 значений соответствующие диапазону 20-50 "настоящего параметра", далее 20 значений, соответствующие "настоящему диапазону "60-80", и наконец последние 10 значений соответствуют "настоящим" значениям 90-100.
Внутри эксперта преобразуем "искусственный" параметр в "настоящий", и в результате имеем оптимизацию только по нужным диапазонам.
У меня в моей Лиге ТС почти так сделано объединение двух "настоящих" параметров (используемого таймфрейма и рабочих дней недели) в один "искусственный" параметр-перечисление.
вот бы добавить к input переменной свойство невидимости в тестере, например у меня в inpt используется Подгружать историю по всем используемым символам или нет, в тестере если не отключить подгрузку, начинается проблема
сейчас посмотрел весь свой input, там много всего что занимает лишние строки в тестере, причем в самом верху, и спускать вниз такие совсем не хочется
вот бы добавить к input переменной свойство невидимости в тестере, например у меня в inpt используется Подгружать историю по всем используемым символам или нет, в тестере если не отключить подгрузку, начинается проблема
сейчас посмотрел весь свой input, там много всего что занимает лишние строки в тестере, причем в самом верху, и спускать вниз такие совсем не хочется
Так а в чём проблема запросить внутри советника, работает ли режим оптимизации, и если работает, то игнорировать переменную?
Так а в чём проблема запросить внутри советника, работает ли режим оптимизации, и если работает, то игнорировать переменную?
тут да можно сделать, я там по ходу пьесы добавил
речь была про список видимости, что в роботе есть много используемых input переменных, а внутри тестера нет никакой необходимости их видеть, просто куча лишних строк
add
но это отметка переменной должна быть что-то типа Доп символ к названию input переменной, что-бы функционал можно было быстро вернуть в тестер при необходимости
С подобным неудобством я для себя справился так. Практически весь код хранится в .mqh-файлах, а для получения готового советника есть один .mq5-файл, в котором оставлены только input-переменные и подключение .mqh. Поэтому если надо уменьшить количество видимых в тестере переменных можно просто создать копию .mq5-файла и убрать слово input для тех переменных, которые не нужны при оптимизации в тестере. И оптимизировать этот новый исполняемый файл.
Вместо искусственных параметров использовал проверку в OnInit(), допустимы ли такие значения параметров. Например, если величина Trailing Stop оказалась больше Take Profit, то такой прогон не нужен. Если в этом случае возвращать INIT_INCORRECT_PARAMETERS, то тестер просто перейдет к следующей комбинации.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
В боте есть модули которые могут быть включены или отключены. У модулей есть свои input параметры, которые прогоняются в оптимизации. Так же, активность задана в оптимизации булевым input'ом. Есть ли какая то возможность при оптимизации игнорировать перебор параметров модуля если он выключен (активность установлена в false)? Иначе, получаем бесполезные прогоны с разными вариациями настроек отключеного модуля.
В документированых возможностях такого не нашел. Может быть есть возможность реализовать это при помощи какого то костыля? Например, проверять на стадии инициализации был ли уже такой же прогон, в котором совпадают input прараметры включеных модулей и вылетать по INIT_FAILED или по намереному обращению к NULL указателю? Если такая возможность есть - то как это повлияет на генетическую оптимизацию?