Не для разработчиков МТ! Чем заменить INIT_PARAMETERS_INCORRECT ? - страница 2

 

Вы можете в OnTesterInit создать свой оптимизационный набор и заставить оптимизатор думать, что оптимизируется только один sinput int NumPass.

Сложно сказать, как это скажется на итоговом результате - будет ли найден нужный глобальный (локальный) экстремум.

Пример не готов предоставить, посмотрите Документацию. Там неплохо написано.

 
fxsaber:

Один из рецептов, чтобы разработчики результат INCORRECT-проходов считали, как ближайший посчитанный ранее CORRECT-проход. Это нивелирует дыры в оптимизационной поверхности.

Вот против этого разработчики и выступают. В этом случае "выживут" другие особи популяции. И генетика начнет работать с ошибками.

 

А если написать функцию, которая бы выдавала только валидные цепочки по номеру ?

Первое, что приходит на ум -  таблица из  117649 значений, а генетика - пусть ищет номера в этой таблице.

 
Sergey Savinkin:

Вот против этого разработчики и выступают. В этом случае "выживут" другие особи популяции. И генетика начнет работать с ошибками.

Я тоже буду против подобного алгоритма. INCORRECT - это недопустимый набор параметров, его нельзя заменять "ближайшим допустимым".

 
Sergey Savinkin:

Вот против этого разработчики и выступают. В этом случае "выживут" другие особи популяции. И генетика начнет работать с ошибками.

Генетика на практике почти всегда ошибается, что есть норма. Без должного исследования в этой области утверждать что-либо по предложенному варианту не возьмусь.

 
Georgiy Merts:

А если написать функцию, которая бы выдавала только валидные цепочки по номеру ?

Первое, что приходит на ум -  таблица из  117649 значений, а генетика - пусть ищет номера в этой таблице.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Не для разработчиков МТ! Чем заменить INIT_PARAMETERS_INCORRECT ?

fxsaber, 2018.07.10 16:22

Вы можете в OnTesterInit создать свой оптимизационный набор и заставить оптимизатор думать, что оптимизируется только один sinput int NumPass.

Сложно сказать, как это скажется на итоговом результате - будет ли найден нужный глобальный (локальный) экстремум.

Сильно зависит от критерия удовлетворенности итоговым результатом.


Очевидно, что если следать полный перебор y = x^2. Затем рандомно перемешать строки опимизации и создать на основе перемешивания новый набор. То ГА не найдет вершину параболлы.

 
fxsaber:

Очевидно, что если следать полный перебор y = x^2. Затем рандомно перемешать строки опимизации и создать на основе перемешивания новый набор. То ГА не найдет вершину параболлы.

Да, тут получается, что эти самые INCORRECT слишком сильно "рвут" пространство фитнесс-функции.

Кроме коренной переработки входных параметров, боюсь, тут ничего не придумаешь.  Пропуски OnTick() - как ты предлагаешь, это просто костыль, заменяющий INCORRECT-параметр, реально же генетический алгоритм при этом все равно "убивается".  Генетика предполагает некоторые "градиенты" результирующей функции, чтобы по ним можно было двигаться к максимумам. А когда у нас INCORRECT'ов больше, чем валидных значений - как ты найдешь этот самый максимум ?

Подозреваю, что кроме полного перебора тут ничего не придумаешь, да и полный перебор найдет крайне неустойчивое решение.
 

Нужно немного уметь задавать входные параметры.

Очень распространенный пример можно привести. Когда оптимизируют суточный интервал торговли, то чаще всего задают суточное время старта и конца интервала - два входных параметра.

Но это много хуже для ГА, чем, например, задать время старта и длительность. Казалось бы, одно и то же, но не для ГА. Во втором случае ГА справится лучше. Хотя "лучше" - довольно субъективная оценка.

 

Georgiy Merts:

когда у нас INCORRECT'ов больше, чем валидных значений - как ты найдешь этот самый максимум ? 

Возьмем все ту же параболу, что привел выше. Допустим, на интервале тестирования 90% значения единственного входного параметра сделаем INCORRECT. Текущий ГА сдохнет на такой задаче. Однако, если действовать предложенным вариантом, то ГА справится.


Думаю, по данным вопросам может помочь @Andrey Dik. Но даже конструктивная критика штатного ГА для него ничем хорошим не заканчивалась...

 
fxsaber:

Возьмем все ту же параболу, что привел выше. Допустим, на интервале тестирования 90% значения единственного входного параметра сделаем INCORRECT. Текущий ГА сдохнет на такой задаче. Однако, если действовать предложенным вариантом, то ГА справится.

Это каким ? Заменой инкорректов ближайшими коректами ??? Боюсь, все зависит от того, как мы распределим эти самые инкорректы. Вполне возможно, что ближайшие корректы - будут находиться в стороне от вершины.

Да и получится, что вместо неверных наборов параметров - у нас будут верные результаты - что также, по-моему, делать нельзя - что ж мы тогда находим-то ? Получим максимум, а у него - некорректный набор параметров ?