Не для разработчиков МТ! Чем заменить INIT_PARAMETERS_INCORRECT ? - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Накидал проверочный советник для мат. режима Оптимизатора
Вот так выглядит график Оптимизации на 8-ми Агентах параллельно в режиме полного перебора без перемешивания проходов (Rand = false)
Здесь хорошо видно, что Агенты выполняют задания пачками.
Чтобы увидеть зависимость от параметра, переключим режим отображения
Вот она родимая парабола, вершину которой (единица) и будем искать через ГА.
В режиме перемешивания (Rand = true), конечно, полный перебор находит нашу вершину
Вот она родимая парабола, вершину которой (единица) и будем искать через ГА.
Без перемешивания ГА не нашел экстремум, но подобрался близко к нему
Понадобилось 179 проходов. Напомню, полный набор заданий - 10001 проходов. Да, задача очень простая, но все же.
Теперь пробудем вариант с перемешиванием (Rand = true)
Снова близко. По логу хорошо видно, что 182 прохода были посчитаны полноценно, а 970 взялись из кеша.
Хороший результат, поэтому, попробуем увеличить количесво точек в интервале.
Хороший результат, поэтому, попробуем увеличить количесво точек в интервале.
Количество точек в интервале один миллион.
Rand = false
Rand = true (из миллиона точек рандомно выбранные пары менялись местами 100 милллионов раз)
Результат говорит о том, что мое самоуверенное заявление
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Не для разработчиков МТ! Чем заменить INIT_PARAMETERS_INCORRECT ?
fxsaber, 2018.07.10 16:27
Очевидно, что если следать полный перебор y = x^2. Затем рандомно перемешать строки опимизации и создать на основе перемешивания новый набор. То ГА не найдет вершину параболлы.
скорее ложно, чем верно.
С другой стороны, выбор фитнесс-функции в качестве параболы крайне недальновиден был изначально, т.к. количество точек, близких к единицу зашкаливает.
Возник только один вопрос к ГА, почему без перемешивания не был найден точный экстремум, ведь выбранная функция идеальна для этого?
С другой стороны, выбор фитнесс-функции в качестве параболы крайне недальновиден был изначально, т.к. количество точек, близких к единицу зашкаливает.
Предполагаю, если выбрать функцию с острым пиком, то после перемешивания ГА все же обломается. А такая функция куда ближе к ТС.
Накидал проверочный советник для мат. режима Оптимизатора
К сожалению, моих знаний не достаточно, чтобы всё это понять )))
Я решил попроще. В общем, я добавил в советник запись в файл лигитимных цепочек. Из 117649 вариантов допустимых оказалось 1953. К слову сказать, полный перебор на интервале 3 дня, Только цены открытия и 0 сделок это заняло
Теперь у меня есть файл. Как это передать для оптимизации пока не знаю. Буду завтра думать...
И почему успешных меньше? Придётся повторить?Предполагаю, если выбрать функцию с острым пиком, то после перемешивания ГА все же обломается. А такая функция куда ближе к ТС.
Так генетика и не заточена под ловлю пиков. Её цель - найти устойчивые области, именно это и требуется для ТС. А пики - это шум, как правило.
Что касается некорректных комбинаций параметров, то они должны отсеиваться на стадии формирования популяции. Т.е. если в результате генного обмена или мутации получается некорректная особь, то нужно повторять её генерацию снова до тех пор, пока не получим корректную. Тогда всё будет ок.
Если же отсеивание по INIT_PARAMETERS_INCORRECT происходит уже после того, как популяция сформирована, тем самым уменьшая размер этой популяции, то это естественно нарушает нормальный механизм генетического отбора. Видимо у MQ реализовано по этому варианту. И при таком раскладе задача топикстартера вряд ли решаема (в общем случае), танцы с бубнами не помогут.
Спасибо за мнение, только здесь не обсуждается архитектура программы. Если не заметили...
Напрасно, напрасно.
Я вот согласен, что твоя проблема именно в неверной архитектуре программы. Думаю, что максимум ты можешь получить только путем полного перебора, и он будет крайне неустойчивым.
Скорее всего используются полные переборы на каждом тике. И это само собой дает тормоза при работе. Если так, то стоит посмотреть в сторону полного перебора только при старте эксперта/открытии бара, а потом чисто проверка последних данных. Подобная оптимизация всегда порядком сокращает потребление ресурсов.
Так генетика и не заточена под ловлю пиков. Её цель - найти устойчивые области, именно это и требуется для ТС. А пики - это шум, как правило.
не совсем так. мало того, даже устойчивые области пространства оптимизации это все равно области с провалами и пиками, ФФ получается далеко не гладкая.
генетика универсальный инструмент, ее можно заточить под оптимизацию рваной ФФ, но тогда гладкую ФФ она будет оптимизировать дольше. в конце концов генетику можно сделать адаптивной.
имхо, штатная генетика должна переваривать сеты с половиной INIT_PARAMETERS_INCORRECT даже не задумываясь. Тем более что эти области обычно хорошо кластеризуются.
но вообще самое правильное решение это преобразование пространства входных параметров.
Напрасно, напрасно.
Я вот согласен, что твоя проблема именно в неверной архитектуре программы. Думаю, что максимум ты можешь получить только путем полного перебора, и он будет крайне неустойчивым.
Да дело не в архитектуре. Дело в наборе функций и порядка их применения. По сути, изначально, эти функции имели единственную постоянную последовательность. Потом я решил, что, возможно, стоит поэксперементировать с порядком их вызова и не вызова некоторых. Реализовал это через INIT_PARAMETERS_INCORRECT. Прогресс ощутимый. Только вот беда с генетической оптимизацией...
Теперь по существу. Файл с лигитимными цепочками создал. Как теперь его использовать? Подозреваю, что надо через onTester, фреймы... Документацию смотрел, но что-то не складывается. Не могу разобраться как с этим бороться.
Есть мысля считать его в массив и уже из него брать данные...