Обсуждение статьи "Роль качества генератора случайных чисел в эффективности алгоритмов оптимизации" - страница 12
![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В схеме нет элемента, отвечающего и/или влияющего на робастность? Что это за элемент?
Способов генерализации может быть много и желательно их все попробовать, чтобы выявить наиболее эффективный. С этой точки зрения, блок-схема будет дополняться по-разному в зависимости от подхода.
Например, может быть "Postprocessing" (для кластеризации) после блока "Result" (который стоит переименовать в "Results", потому что для кластеризации нужны все результаты, а не один).
Или некий "Controller" между "Fitness function" и "Optimization Algorithm", который может выполнять всякие разные функции, в частности, добавлять случайный шум.
Еще на схеме явно не хватает "Input Data". Тогда её можно было бы делить на IS/OOS и применять к ним блоки параллельно, сверяясь по ходу.
Наконец, есть известный подход Walk-Forward Optimization (правда, специфичный для таймсериз, а не оптимизации в общем виде). Для него текущая схема - это только один этап оптимизации, которых на самом деле должно быть подготовлено несколько неким внешним блоком "Manager" - например, несколько 12 месячных оптимизаций со сдвигом на месяц. И тут открывается новое измерение для исследований - фигурально выражаясь, мы смотрим как "дышит" ФФ с течением времени и учимся предсказывать её следующую форму (каким образом? - тут потребуется новая серия статьей). Или наоборот - видим, что она меняется настолько непредсказуемо, что либо ТС, либо финансовый инструмент явно не подходят друг другу... или нужно уменьшить шаг форварда до 1 недели, чтобы оно-таки заработало. Это к вопросу не только устойчивости, но и длительности этой устойчивости.
Способов генерализации может быть много и желательно их все попробовать, чтобы выявить наиболее эффективный. С этой точки зрения, блок-схема будет дополняться по-разному в зависимости от подхода.
Например, может быть "Postprocessing" (для кластеризации) после блока "Result" (который стоит переименовать в "Results", потому что для кластеризации нужны все результаты, а не один).
Или некий "Controller" между "Fitness function" и "Optimization Algorithm", который может выполнять всякие разные функции, в частности, добавлять случайный шум.
Еще на схеме явно не хватает "Input Data". Тогда её можно было бы делить на IS/OOS и применять к ним блоки параллельно, сверяясь по ходу.
Наконец, есть известный подход Walk-Forward Optimization (правда, специфичный для таймсериз, а не оптимизации в общем виде). Для него текущая схема - это только один этап оптимизации, которых на самом деле должно быть подготовлено несколько неким внешним блоком "Manager" - например, несколько 12 месячных оптимизаций со сдвигом на месяц. И тут открывается новое измерение для исследований - фигурально выражаясь, мы смотрим как "дышит" ФФ с течением времени и учимся предсказывать её следующую форму (каким образом? - тут потребуется новая серия статьей). Или наоборот - видим, что она меняется настолько непредсказуемо, что либо ТС, либо финансовый инструмент явно не подходят друг другу... или нужно уменьшить шаг форварда до 1 недели, чтобы оно-таки заработало. Это к вопросу не только устойчивости, но и длительности этой устойчивости.
То, что Вы назвали - имеет право быть и во многих случаях должно быть, но оно относится "симптоматическому лечению", не рассматривает причины робастности или неробастности полученных результатов и является внешними мерами (типа, делать диагностику по периодическим замерам температуры больного - это и не плохо и не хорошо, просто может не дать возможности получить объективный анамнез).
На самом деле всё, что реально влияет на робастность результатов уже есть в этой схеме.
То, что Вы назвали - имеет право быть и во многих случаях должно быть, но оно относится "симптоматическому лечению", не рассматривает причины робастности или неробастности полученных результатов и является внешними мерами (типа, делать диагностику по периодическим замерам температуры больного - это и не плохо и не хорошо, просто может не дать возможности получить объективный анамнез).
На самом деле всё, что реально влияет на робастность результатов уже есть в этой схеме.
Тогда ждем пояснений и демонстраций на тестах.
Тогда ждем пояснений и демонстраций на тестах.
Ок. Хотелось бы ещё услышать видение Сабера и Андрея, дополнительно, как участников обсуждения темы робастности.
Если я опубликую рабочую методу получения робастных результатов систем на нестационарных процессах, то сразу получу нобелевку и памятник при жизни из цельного куска малахита, что очень привлекательно, но навряд ли осуществимо. Но, по крайней мере, понимать, что может влиять на робастность результатов, а что не может - уже хорошо.
Вопрос в том, что дальше делать с набором этих сетов с вершинами "холмов". Раньше мы имели один глобальный максимум как решение алгоритма оптимизации, допустим теперь их 50. Но они не приближают к решению проблемы устойчивости.
Допустим, ТС может словить относительно устойчивую закономерность при определенных своих настройках. При этом глобальный максимум OnTester не попадает в эти настройки, и мы не знаем, какую ФФ выбрать, чтобы попадать в искомое яблочко.
Если некую закономерность в ценах способна воспроизвести ТС, то искомый набор будет соответствовать какой-то локальной вершине ФФ. Некоторые высокие вершины будут соответствовать несистемным белым лебедям, что были на Sample. Из-за них на классических АО упускаются более низкие, но потенциально устойчивые наборы входных.
Простое утверждение, которое легко проверяется на практике. Возьмите почти любую ТС с большим количеством непересекающихся позиций. Например, 10 таких позиций в сутки. Найдите глобальный максимум InputsMax1 за весь 2023 год и InputsMax2 за лето 2023 года. Очевидно, что летом 2023 года никакой АО не найдет InputsMax1 даже рядом. Но при этом обнаружите, что среди локальных вершин за лето 2023 есть та, которая очень близка к InputsMax1.
Возвращаюсь к вопросу. 50 найденных вершин нужно прогнать на OOS. И если среди них будет найден условный InputsMax1, то копаем дальше. Если нет - выбрасываем (меняем символ).
В схеме, конечно же, нет ничего, что могло бы повлиять на рабустность
В схеме только то, что влияет на подгонку. Чем лучше эта схема, тем лучше подгонка.
Если речь о ФФ, то она никак не влияет на робусность.
Ведь абсолютно очевидно, если вы каждый день будете получать новую поверхность ФФ, например при "оптимизации" двух параметров, а потом склеите полученные кадры, то получиться примерно такое:
Ну и что с того, если вы даже правильно поймали нужный холм? Это холм истории, но не будущего. В чем смысл?
Так что с Дмитриевским согласен. Подгонка под историю - она и в Африке подгонка, даже если ее обозвать оптимизацией методом Макаки, Журавля или Осьминога.
Например, наглядный пример.
Берем стратегию десяти гармоник, которые необходимо сложить, чтобы получить экстраполяционную линию для принятия решения на открытия сделок.
Каждая гармоника - это три параметра: амплитуда, частота, сдвиг по фазе. Итого 10*3=30 искомых параметров.
Конечно, можно их вычислить с помощью быстрого преобразования Фурье за несколько миллисекунд, но мы не будем искать легких путей, а будем подбирать лучшую комбинацию этих 30 параметров с помощью перебора при оптимизации, генетического алгоритма и статей Дика.
Надеюсь, на хорошем суперкомпе за пару дней после генетического перебора 30*10000 = 300000 комбинаций всех 30 параметров, мы получим нужную комбинацию параметров, и так каждую неделю будем переоптимизировать данную стратегию на выходных.
И вот что мы в итоге получим на недельном графике:
как видим, красная линия экстраполяции мало нам поможет в торговле несмотря на сожженные сотни киловат энергии при оптимизации :)) Т.к. рынок все время меняется.
Мораль сей басни: Нужно не перебирать параметры, а вычислять их в процессе торговли внутри ТС для того, чтобы, как минимум, не жечь лишнюю электроэнергию. Это если быть ООЧЧЕЕННЬЬ кратким
Для любого параметра всегда найдется своё "быстрое преобразование Фурье".