Оптимизация, не тривиальная задача... - страница 2

Вот ещё статеечка

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

Спасибо за статью. Хотя раньше надо было "Спасибо" говорить. Но лучше поздно,

Я опять таки ничего не продаю на данном форуме, если и рекламирую, то косвенно и по теме как говорится.

Суть моего вопроса я описал выше, функция есть и использовать её может каждый, вопрос лишь в том как правильней, логичнее, математически и т.д. и т.п. её применять. Знаю что есть на форуме матиматики, физики, аналитики, программисты и что у людей нет идей как это применить.

Вот допустим лично моё мнение (набросок).

Оптимизируем советника, пишем все параметры в файл, расчётные по сделкам + значение переменных. В файл попадают записи проходящие по фильтру (ибо нечего плодит лишние строки (хотя не факт)), фильтр допустим ЧИСТАЯ ПРИБЫЛЬ. Если прибыль новой оптимизации больше последней максимальной известной, делаем запись в файл.

Допустим имеем 10000 положительных вариантов оптимизации. как правило 30-60% это однотипный набор переменных и как правило прибыль у этих прогонов равна.

Дальше парсим список это простое занятие, все значения в массивах или одном многомерном массиве.

Дальше сложности, а именно, нужно выявить оптимальный вариант из имеющихся в файле. В данном случае подходит метод сортировки и уменьшения числа претендентов на лучший вариант.

Отсортировали по максимальной прибыли (MAX - > MIN), какую часть массива выкинуть в мусорку? 1/2, 1/3, 1/5 тут у меня сомнения и вот почему. В файле может быть не так много записей с положительными результатами, можем потерять массу достойных вариантов если выкинем 1/2 например. Даже если выкинули, то после следующей сортировки, допустим по МАТОЖИДАНИЮ (MAX - > MIN), нужно выкинуть лишнее, опять вопрос сколько выкидывать? Можно довыкидываться как говорится, что вариантов не останется, ну или на кройняк один то останется всегда, но не всегда оптимальный.

Если использовать функцию из статьи (см. выше), то имеем 31 переменную для сортировки, про возможные варианты и их комбинации я вообще молчу.

Поэтому я и задаю вопрос кто как бы поступил и почему.

https://www.mql5.com/ru/code/9202

А если так. Сам не пробовал, предложение-предположение.
Порядок:
1. Прогон оптимизации
2. Прогон всех(!) результатов на OOS
3. Применяем методы классификации (той же сеткой или деревьями решений, без разницы) по признаку прибыльности.

Таким образом, можно выявить параметры, при которых ТС ещё будет приносить прибыль в будущем.(не ругаться, не пинаться и не плеваться попросил бы)
Одними сортировками не найти подходящих параметров ТС. имхо

ЗЫ Сделаю оговорку. Это не одно и тоже, что классификация результатов оптимизации ТС картами Кохонена и др. Нуно классифицировать результаты на OOS

Вы не совсем правы. Нектр. вещи удобнее решать численными методами - здесь в качестве таковых выступает оптимизация.

Например, для работы ТС требуется узнать среднюю нешумовую ширину канала. Можно ее вычислить (через волатильность и т.п.), а можно подобрать в оптимизаторе - т.е. решить задачу численно. Порой, это бывает точнее, т.к. через ф-ю не все параметры возможно учесть.

Я уж не беру такой класс задач, где возможно только численное решение. Вы вышку изучали? Тогда должны знать, что думать, оно, конечно, полезно, но до известного предела...)))))))))

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

Как указано в описании: "Проводится оптимизация на одном временном участке, по заданным критериям выполняется выбор лучших результатов оптимизации и проводится проверочное тестирование на другом временном участке".

Имея хотя-бы 5000 положительных результатов после оптимизации, задолбаешься каждый проверять на другом участке. Да и как собственно проверить если оптимизацию делаешь по принципу (сейчас - некоторое время), участка в будущем на котором проверить как бы нет. В тестере можно поиграться и типо заручится доверием что проверяя на другом участке он не сольёт. только вот для текущей ситуации оптимизации это не подходит.

Мне как раз импонирует вариант, указанный в описании. Именно его я и пользую при ручной оптимизации. Бэк-тест делается с отступом от сегодняшнего времени, оставляя участок для форварда. Из положительных результатов бэк-теста по своим критериям отбираются лучшие, из 5000 остается в лучшем случае 50. Эти 50 прогоняются на форварде. Из выживших на форварде отбираются имеющие наклон линии баланса наиболее близкий к полученному на участке оптимизации. Оставшиеся, конечно, не дают 100%-й гарантии, но это лучшее, что можно выжать из этого цикла.
И я бы не стал доверять результатам оптимизации в ходе реальной торговли, проведенной в упор, по сегодняшний день. При самых лучших критериях останется масса нежизнеспособных вариантов.