Обсуждение статьи "Самоадаптирующийся алгоритм (Часть III): Отказываемся от оптимизации" - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
.. Я думаю что не нужно для каждой пары пересчитывать эти эталонные значения в самом советнике. Можно просто скрипт какой нибудь сделать просто который запустил он помолотил пару дней и все вот тебе эталонные значения в файлик, а роботы пусть читают с файла. Год прошел пересчитал. Вряд ли там эти распределения изменятся даже за такой промежуток времени. Даже если изменятся то не сильно...
Голые математические данные вообще не изменятся. Предлагаю кэшировать эти расчёты. Прикрепил файлик с расчетами этих самых факториалов, вероятностей, сумм вероятностей, расчетной средней амплитуды, с кэшированием этого всего на время работы. Полагаю, кому-то ещё кроме меня тоже может пригодиться. Так что расчет этих значений, хоть на каждом баре, уже не напрягает.
А вот построение блоков в прошлое, на каждом новом баре заново, да для нескольких размеров блоков, это да... Чем больше размер, тем больше надо обработать баров, чтобы набрать необходимое для анализа количество блоков такого размера.
Для построения блока я использовал OHLC, а не только С. На мой взгляд, предположить, что цена проходит (O->H->L->C) для down- и (O->L->H->C) для up-баров, несколько полезнее, чем принять к расчетам только close. Таким образом, конечно, увеличивается количество вычислений не намного (в абсолютных затратах времени), но есть и плюсы. К примеру, необходимое количество backward-блоков набирается быстрее. И при переходе с М1 на М5 картинка набора меняется незначительно. А при смене на М15 и выше изменения отсутствуют или еще незначительнее, в сравнении с М5. Что тоже предоставляет перспективы для улучшения быстродействия.. При построении forward-блоков уже не так весело, поскольку "в движении" можно построить одну картинку (например, сразу по тикам), а при восстановительном пересчете - уже другую. Опять же, если forward-блоки предполагается набирать по закрытию очередного бара, то можно бы и OHLC взять."Я, конечно, не мастер", как говаривал Панда, но собранное мной на коленке по мотивам статьи, после нескольких оптимизаций (где первая - это кэш статрасчетов) дает примерно такие результаты:
- валюта USDJPY М1, по ценам открытия, набор блоков от 24 до 40, размер блока от 90 пунктов и далее +10% к предыдущему (256п max), всего 12 размеров.
- на периоде в календарный месяц простой прогон занимает в среднем 2.5 минуты, где доля обработки торговых операций от силы 10%. Чем жестче требования к выявлению тренда, тем реже находится сигнал открытию, тем больше переборов в сторону увеличения размера блока и времени на поиск. Чем чаще сигнал, тем чаще фиксация back-блоков и расчет только fwd, что о-о-о-очень ускоряет.
С результатом прогона 2.5 минуты на месяц обсчета выявление нюансов или оптимизация каких-то параметров работы затруднительны, но возможны :)
Идея в статье интересна и вроде бы проста и понятна. Но, как говорила одна девушка, "я не поняла, поняла ли я...". Всё изложенное выше касается не самой идеи или её оценки, а только конкретной её реализации (конечно, неполной и в силу собственного понимания).
P.S. А началось-то вообще с сомнений, что на 24 блоках среднее блуждание будет 3.8 :)
Голые математические данные вообще не изменятся. Предлагаю кэшировать эти расчёты. Прикрепил файлик с расчетами этих самых факториалов, вероятностей, сумм вероятностей, расчетной средней амплитуды, с кэшированием этого всего на время работы. Полагаю, кому-то ещё кроме меня тоже может пригодиться. Так что расчет этих значений, хоть на каждом баре, уже не напрягает.
А вот построение блоков в прошлое, на каждом новом баре заново, да для нескольких размеров блоков, это да... Чем больше размер, тем больше надо обработать баров, чтобы набрать необходимое для анализа количество блоков такого размера.
Для построения блока я использовал OHLC, а не только С. На мой взгляд, предположить, что цена проходит (O->H->L->C) для down- и (O->L->H->C) для up-баров, несколько полезнее, чем принять к расчетам только close. Таким образом, конечно, увеличивается количество вычислений не намного (в абсолютных затратах времени), но есть и плюсы. К примеру, необходимое количество backward-блоков набирается быстрее. И при переходе с М1 на М5 картинка набора меняется незначительно. А при смене на М15 и выше изменения отсутствуют или еще незначительнее, в сравнении с М5. Что тоже предоставляет перспективы для улучшения быстродействия.. При построении forward-блоков уже не так весело, поскольку "в движении" можно построить одну картинку (например, сразу по тикам), а при восстановительном пересчете - уже другую. Опять же, если forward-блоки предполагается набирать по закрытию очередного бара, то можно бы и OHLC взять."Я, конечно, не мастер", как говаривал Панда, но собранное мной на коленке по мотивам статьи, после нескольких оптимизаций (где первая - это кэш статрасчетов) дает примерно такие результаты:
- валюта USDJPY М1, по ценам открытия, набор блоков от 24 до 40, размер блока от 90 пунктов и далее +10% к предыдущему (256п max), всего 12 размеров.
- на периоде в календарный месяц простой прогон занимает в среднем 2.5 минуты, где доля обработки торговых операций от силы 10%. Чем жестче требования к выявлению тренда, тем реже находится сигнал открытию, тем больше переборов в сторону увеличения размера блока и времени на поиск. Чем чаще сигнал, тем чаще фиксация back-блоков и расчет только fwd, что о-о-о-очень ускоряет.
С результатом прогона 2.5 минуты на месяц обсчета выявление нюансов или оптимизация каких-то параметров работы затруднительны, но возможны :)
Идея в статье интересна и вроде бы проста и понятна. Но, как говорила одна девушка, "я не поняла, поняла ли я...". Всё изложенное выше касается не самой идеи или её оценки, а только конкретной её реализации (конечно, неполной и в силу собственного понимания).
P.S. А началось-то вообще с сомнений, что на 24 блоках среднее блуждание будет 3.8 :)
Да, математика у меня кешируется во время работы. Тесты очень долго идут... Я готовил тесты для следующей статьи, до нового года поставил тестироваться. Тестер однопоточный, поэтому я разбил тесты на участки по 2 года (28 валютных пар) и загрузил 5 терминалов. Все это у меня тестировалось 14 дней и потом сломался роутер, я начал подключать инет кабелем напрямую и вылезла ошибка send error 10054 во всех тестерах... Поэтому следующая статья не скоро... кстати может кто знает что за ошибка такая send error 10054 и как ее в будущем избежать?
В статье не все описано пока, почти все описано в ТЗ, но там тоже не все)). Сейчас делаю версию намного совершеннее.
Как кстати сомнения насчет цифры 3,8 исчезли?)
Скину пока результаты за 1,5 года с 2010.06.25 по 2012.02.27. Это без оптимизации по 28 инструментам одновременно. Параметры для всех инструментов одинаковые
кстати может кто знает что за ошибка такая send error 10054 и как ее в будущем избежать?
Как кстати сомнения насчет цифры 3,8 исчезли?)Сомнения исчезли, математика же ж.
а 10054 - это предположительно ошибка сетевого протокола, из-за потери сетевого соединения. То, что потом назад воткнули, роли не сыграло. Проблема обычно проявляется во многих программах при выдирании линка из сетевой карты (или отключения роутера). Винда при этом (особенно если ip по dhcp получен) начинает думать, что рабочего сетевого устройства у нее больше нет, поэтому сетевые сервисы обламываются. При этом обламываются и программы, работающие по сетевым соединениям локально, например на свой локальный адрес 127.0.0.1.
Мне помогало такое: создавал в компе виртуальное сетевое устройство (loopback, можно погуглить), назначал на него ИП адрес типа 127.0.1.1, в hosts прописывал имя своего ПК и этот адрес. Получается, в системе есть всегда активное сетевое устройство, ПК сам себе доступен по имени и этому адресу, сетевые сервисы стартуют, программы которые сами с собой по tcp/ip - тоже.
Ну, и еще ipv6 всегда отключаю.
Опять же, давно такого не ловил, то ли я всегда на коннекте, то ли что-то где-то поменялось ...Сомнения исчезли, математика же ж.
а 10054 - это предположительно ошибка сетевого протокола, из-за потери сетевого соединения. То, что потом назад воткнули, роли не сыграло. Проблема обычно проявляется во многих программах при выдирании линка из сетевой карты (или отключения роутера). Винда при этом (особенно если ip по dhcp получен) начинает думать, что рабочего сетевого устройства у нее больше нет, поэтому сетевые сервисы обламываются. При этом обламываются и программы, работающие по сетевым соединениям локально, например на свой локальный адрес 127.0.0.1.
Мне помогало такое: создавал в компе виртуальное сетевое устройство (loopback, можно погуглить), назначал на него ИП адрес типа 127.0.1.1, в hosts прописывал имя своего ПК и этот адрес. Получается, в системе есть всегда активное сетевое устройство, ПК сам себе доступен по имени и этому адресу, сетевые сервисы стартуют, программы которые сами с собой по tcp/ip - тоже.
Ну, и еще ipv6 всегда отключаю.
Опять же, давно такого не ловил, то ли я всегда на коннекте, то ли что-то где-то поменялось ...а, спасибо... похоже понял, я случайно сетевую карту отключил, наверное тут винда впала в панику и тестер остановился. Спасибо!
Please attach the sample MT5 EA for us to follow your ideas and test your theory.
Please attach the sample MT5 EA for us to follow your ideas and test your theory.
The algorithm is not distributed in the public domain, but in the next article I will show how it works using the example of backtests.
Приветствую.
Некоторые соображения и их результаты. Немножко длинно.
Два подхода к анализу отклонений блоков: график есть случайное блуждание - применяем стат.функции (на факториалах и пр.) или график не-совсем-случайное движение - используем стат. данные по движениям прошлого. Если достаточное время следили за формированием графика блоков, то, наверное, заметили, что график зависит от начальной точки построения. Если мы строим график на каждом открытии свечи, то получаем на свече N график немного не такой, как на N+1. Отсюда два варианта для формирования стат.данных по прошлым блокам: также на каждом открытии свечи или периодически, например, раз в (час/день/неделю), но при этом и график блоков должен строиться от той же нулевой точки. Подход с обсчетом всего и вся заново на каждом баре возможен, но он очень медленный.
Я отчаялся с таким вариантом что-то подобрать/проверить в тестере, и все догадки или оптимальные параметры проверял на демо, в онлайн, контролируя результаты по графику изменения Эквити/баланса тоже онлайн. Должен сказать, что на тех коротких периодах (последний с 21/01 по текущее время) алгоритм (ну, как я его понял и реализовал) достаточно устойчив. Открывал, кстати, не на каждом баре при сигнале, а при новом сигнале (т.е. был сигнал buy на H блока 150п, купил, следующий открывал на Buy H=165, и то, если оно в минус идет. Т.к. при положительном развитии дисбаланс в блуждании уменьшается, соответственно, и сигнал пропадает), В stopout ушел только один демо-счет из 8, с очень агрессивными настройками, при балансе 1000$ и плече 1:1000 использовал 48 валютных пар, металлы, 2 нефти, без контроля хеджа по валютам ("хедж" - когда купили USDJPY, нельзя купить USDCAD, но можно купить EURUSD и т.д на всем наборе символов, в статье есть), на сделку выделял 10$, лот адаптивный, зависит от размера блока, выход только по накопленному профиту на сумме сделок по символу или по сумме профита по всем открытым символам.
Устойчив, да, но просадки значительные. Когда зашли "не в ту сторону" и продолжаем наращивать позицию, находясь в минусе, это понятно. Но менее агрессивные настройки остальные счетА (мн.ч.) не убили, да.
Возвращаясь к способу расчета блоков. Я сейчас использую такой вариант. Берем опорную точку - закрытие предыдущей пятницы. От нее строим (1 раз!) в прошлое наборы блоков с высотами как в статье (*1.1). За начальную высоту принял (iATR(sy, PERIOD_M1, 1440) X 5) от начальной точки. Наборы сразу строим длиной StepMax+MAX_STAT (например, 48+1000), и вычисляем распределение частот пробега и пр. для каждой длины в блоках (пусть от 24 до 48). Далее на каждом новом баре достраиваем наборы вперед, ищем сигнал для каждого H в диапазоне длин (к примеру) [24;48] блоков, ориентируясь на рассчитанную ранее статистику, выбираем подходящий, принимаем решение об открытии нового, закрытии/наращивании старого и пр... Данный подход дает значительный прирост в скорости расчетов, и, полагаю, не сильно отличается от предложенного в статье (расчет "с нуля" на каждом баре). При этом появляются некоторые дополнительные возможности. В частности, если в течение недели уровни не изменяются, то при наличии сигнала на H=180п (к примеру) можно расставить сетку ордеров в ожидаемом направлении движения...
Далее. Такой подход позволил не использовать чистую статистику, а сразу замерять конкретные распределения и ожидания на конкретном символе и размере блока. Что несколько улучшило результаты, по сравнению с "чистым блужданием". При этом собирались данные длин блужданий по модулю (также и при статфункциях использовал длину движения по модулю, да оно и понятно, что случайное блуждание, в общем-то, симметрично относительно нуля). Отдельно отмечу, что размер выборки в 1000 единиц можно поименовать "статистически достоверным" достаточно условно, но не суть.
Ну а далее я попробовал собирать распределение длин пробега в блоках с учетом их знака (вверх или вниз). И результаты ухудшились. Неожиданно.
Проверял на наборе символов "28 мажоров" и на наборах для каждого мажора (*AUD* и т.п.). Это уже в МТ5. Проверял разные периоды, параметры построения блоков, различные нюансы входа-выхода...
Общий вывод (по имеющимся результатам) - при учете направления длины движений в блоках результативность системы падает. Если кто-то может это объяснить, буду рад узнать что и как. Также, если у кого-то есть аналогичный опыт, но противоположный результат, буду рад обсудить-сравнить.
Приветствую.
Некоторые соображения и их результаты. Немножко длинно.
Два подхода к анализу отклонений блоков: график есть случайное блуждание - применяем стат.функции (на факториалах и пр.) или график не-совсем-случайное движение - используем стат. данные по движениям прошлого. Если достаточное время следили за формированием графика блоков, то, наверное, заметили, что график зависит от начальной точки построения. Если мы строим график на каждом открытии свечи, то получаем на свече N график немного не такой, как на N+1. Отсюда два варианта для формирования стат.данных по прошлым блокам: также на каждом открытии свечи или периодически, например, раз в (час/день/неделю), но при этом и график блоков должен строиться от той же нулевой точки. Подход с обсчетом всего и вся заново на каждом баре возможен, но он очень медленный.
Я отчаялся с таким вариантом что-то подобрать/проверить в тестере, и все догадки или оптимальные параметры проверял на демо, в онлайн, контролируя результаты по графику изменения Эквити/баланса тоже онлайн. Должен сказать, что на тех коротких периодах (последний с 21/01 по текущее время) алгоритм (ну, как я его понял и реализовал) достаточно устойчив. Открывал, кстати, не на каждом баре при сигнале, а при новом сигнале (т.е. был сигнал buy на H блока 150п, купил, следующий открывал на Buy H=165, и то, если оно в минус идет. Т.к. при положительном развитии дисбаланс в блуждании уменьшается, соответственно, и сигнал пропадает), В stopout ушел только один демо-счет из 8, с очень агрессивными настройками, при балансе 1000$ и плече 1:1000 использовал 48 валютных пар, металлы, 2 нефти, без контроля хеджа по валютам ("хедж" - когда купили USDJPY, нельзя купить USDCAD, но можно купить EURUSD и т.д на всем наборе символов, в статье есть), на сделку выделял 10$, лот адаптивный, зависит от размера блока, выход только по накопленному профиту на сумме сделок по символу или по сумме профита по всем открытым символам.
Устойчив, да, но просадки значительные. Когда зашли "не в ту сторону" и продолжаем наращивать позицию, находясь в минусе, это понятно. Но менее агрессивные настройки остальные счетА (мн.ч.) не убили, да.
Возвращаясь к способу расчета блоков. Я сейчас использую такой вариант. Берем опорную точку - закрытие предыдущей пятницы. От нее строим (1 раз!) в прошлое наборы блоков с высотами как в статье (*1.1). За начальную высоту принял (iATR(sy, PERIOD_M1, 1440) X 5) от начальной точки. Наборы сразу строим длиной StepMax+MAX_STAT (например, 48+1000), и вычисляем распределение частот пробега и пр. для каждой длины в блоках (пусть от 24 до 48). Далее на каждом новом баре достраиваем наборы вперед, ищем сигнал для каждого H в диапазоне длин (к примеру) [24;48] блоков, ориентируясь на рассчитанную ранее статистику, выбираем подходящий, принимаем решение об открытии нового, закрытии/наращивании старого и пр... Данный подход дает значительный прирост в скорости расчетов, и, полагаю, не сильно отличается от предложенного в статье (расчет "с нуля" на каждом баре). При этом появляются некоторые дополнительные возможности. В частности, если в течение недели уровни не изменяются, то при наличии сигнала на H=180п (к примеру) можно расставить сетку ордеров в ожидаемом направлении движения...
Далее. Такой подход позволил не использовать чистую статистику, а сразу замерять конкретные распределения и ожидания на конкретном символе и размере блока. Что несколько улучшило результаты, по сравнению с "чистым блужданием". При этом собирались данные длин блужданий по модулю (также и при статфункциях использовал длину движения по модулю, да оно и понятно, что случайное блуждание, в общем-то, симметрично относительно нуля). Отдельно отмечу, что размер выборки в 1000 единиц можно поименовать "статистически достоверным" достаточно условно, но не суть.
Ну а далее я попробовал собирать распределение длин пробега в блоках с учетом их знака (вверх или вниз). И результаты ухудшились. Неожиданно.
Проверял на наборе символов "28 мажоров" и на наборах для каждого мажора (*AUD* и т.п.). Это уже в МТ5. Проверял разные периоды, параметры построения блоков, различные нюансы входа-выхода...
Общий вывод (по имеющимся результатам) - при учете направления длины движений в блоках результативность системы падает. Если кто-то может это объяснить, буду рад узнать что и как. Также, если у кого-то есть аналогичный опыт, но противоположный результат, буду рад обсудить-сравнить.
Да, график зависит от начальной точки построения, это сделано специально по двум причинам, чтобы алгоритм несмортя на ошибки округления цены при помощи блоков, лучше находил максимальный масштаб и вторая причина, чтобы избежать подгонки под историю. Когда график меняется в зависимости от начала точки отсчета, можно точнее оценить качество самого алгоритма.
В тестере я проверял и покажу в следующей статье много тестов того, как это работает. На демо долго и не информативно. Тест 1 года по 28 валютным парам у меня занимает 15 суток (Ryzen 3700). В том виде, в котором это описано, доходности не велики, но он проходит бектесты очень устойчиво. Сейчас улучшаю алгоритм.
По поводу стат характеристик инструмента есть особенность. Их можно снимать и на основе них корректировать процент перевеса, но нужно использовать большие значения выборок, чтобы оценить характер инструмента в целом. Локальные отклонения можно отлавливать, но для других целей. Когда я тестировал, то на акциях хорошо работает раздельные параметры перевеса для длинных и коротких позиций, то есть когда учитывается ассиметрия, становится лучше, это тоже вкратце покажу в следующей статье.
Начальный размер блоков тоже нужно подстраивать под текущую ситуацию на рынке. Я изначально сделал через волатильность, но сейчас переделываю, чтобы учитывались особенности рынка.
Но сама идея в том, чтобы сначала сделать базовый алгоритм, а потом обвешивать его статистикой. Статистику нельзя просто так измерять, нужно учитывать, что мы измеряем стат характеристики на большом окне и если они отклоняются от случайного блуждания, то в будущем они будут стремиться к нему, нужно использовать заранее неоптимальные параметры. Причем статистика должна быть не голая, а с учетом теории, вот про теорию я и не писал по тому что не доказывал ее, а писать то, что не доказано, мне не нравится.
В общем алгоритм - заготовка и на данном этапе его задача не сливать и хоть что-то зарабатывать.