Не для разработчиков МТ! Чем заменить INIT_PARAMETERS_INCORRECT ? - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вы можете в OnTesterInit создать свой оптимизационный набор и заставить оптимизатор думать, что оптимизируется только один sinput int NumPass.
Сложно сказать, как это скажется на итоговом результате - будет ли найден нужный глобальный (локальный) экстремум.
Пример не готов предоставить, посмотрите Документацию. Там неплохо написано.
Один из рецептов, чтобы разработчики результат INCORRECT-проходов считали, как ближайший посчитанный ранее CORRECT-проход. Это нивелирует дыры в оптимизационной поверхности.
Вот против этого разработчики и выступают. В этом случае "выживут" другие особи популяции. И генетика начнет работать с ошибками.
А если написать функцию, которая бы выдавала только валидные цепочки по номеру ?
Первое, что приходит на ум - таблица из 117649 значений, а генетика - пусть ищет номера в этой таблице.
Вот против этого разработчики и выступают. В этом случае "выживут" другие особи популяции. И генетика начнет работать с ошибками.
Я тоже буду против подобного алгоритма. INCORRECT - это недопустимый набор параметров, его нельзя заменять "ближайшим допустимым".
Вот против этого разработчики и выступают. В этом случае "выживут" другие особи популяции. И генетика начнет работать с ошибками.
Генетика на практике почти всегда ошибается, что есть норма. Без должного исследования в этой области утверждать что-либо по предложенному варианту не возьмусь.
А если написать функцию, которая бы выдавала только валидные цепочки по номеру ?
Первое, что приходит на ум - таблица из 117649 значений, а генетика - пусть ищет номера в этой таблице.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Не для разработчиков МТ! Чем заменить INIT_PARAMETERS_INCORRECT ?
fxsaber, 2018.07.10 16:22
Вы можете в OnTesterInit создать свой оптимизационный набор и заставить оптимизатор думать, что оптимизируется только один sinput int NumPass.
Сложно сказать, как это скажется на итоговом результате - будет ли найден нужный глобальный (локальный) экстремум.
Сильно зависит от критерия удовлетворенности итоговым результатом.
Очевидно, что если следать полный перебор y = x^2. Затем рандомно перемешать строки опимизации и создать на основе перемешивания новый набор. То ГА не найдет вершину параболлы.
Очевидно, что если следать полный перебор y = x^2. Затем рандомно перемешать строки опимизации и создать на основе перемешивания новый набор. То ГА не найдет вершину параболлы.
Да, тут получается, что эти самые INCORRECT слишком сильно "рвут" пространство фитнесс-функции.
Кроме коренной переработки входных параметров, боюсь, тут ничего не придумаешь. Пропуски OnTick() - как ты предлагаешь, это просто костыль, заменяющий INCORRECT-параметр, реально же генетический алгоритм при этом все равно "убивается". Генетика предполагает некоторые "градиенты" результирующей функции, чтобы по ним можно было двигаться к максимумам. А когда у нас INCORRECT'ов больше, чем валидных значений - как ты найдешь этот самый максимум ?
Подозреваю, что кроме полного перебора тут ничего не придумаешь, да и полный перебор найдет крайне неустойчивое решение.Нужно немного уметь задавать входные параметры.
Очень распространенный пример можно привести. Когда оптимизируют суточный интервал торговли, то чаще всего задают суточное время старта и конца интервала - два входных параметра.
Но это много хуже для ГА, чем, например, задать время старта и длительность. Казалось бы, одно и то же, но не для ГА. Во втором случае ГА справится лучше. Хотя "лучше" - довольно субъективная оценка.
Georgiy Merts:
когда у нас INCORRECT'ов больше, чем валидных значений - как ты найдешь этот самый максимум ?
Возьмем все ту же параболу, что привел выше. Допустим, на интервале тестирования 90% значения единственного входного параметра сделаем INCORRECT. Текущий ГА сдохнет на такой задаче. Однако, если действовать предложенным вариантом, то ГА справится.
Думаю, по данным вопросам может помочь @Andrey Dik. Но даже конструктивная критика штатного ГА для него ничем хорошим не заканчивалась...
Возьмем все ту же параболу, что привел выше. Допустим, на интервале тестирования 90% значения единственного входного параметра сделаем INCORRECT. Текущий ГА сдохнет на такой задаче. Однако, если действовать предложенным вариантом, то ГА справится.
Это каким ? Заменой инкорректов ближайшими коректами ??? Боюсь, все зависит от того, как мы распределим эти самые инкорректы. Вполне возможно, что ближайшие корректы - будут находиться в стороне от вершины.
Да и получится, что вместо неверных наборов параметров - у нас будут верные результаты - что также, по-моему, делать нельзя - что ж мы тогда находим-то ? Получим максимум, а у него - некорректный набор параметров ?