System Development Framework 2.0: Исследования практика

В предыдущем посте мы коснулись теоретических аспектов исследований в рамках System Development Framework 2.0, теперь пришло время поговорить о практике. Как я писал раньше, основной задачей моего фреймворка – является минимизация человеческого присутствия в принятии решений, а также отладка всех механизмов при создании торговых систем. По своему опыту я осознал, что достаточно трудно делать первый шаг в исследованиях, потому-что часто приходится идти на ощупь или искать черную кошку в темной комнате, особенно если ее там нет :)
Стандартизация бизнес процессов – это то что нужно любому бизнесу, без нее у вас может получиться в лучшем случае элитное производство штучного продукта, но никогда не получится массового производства, потому что на каждой технологической операции вы будете терять какое-то время. А время для трейдера – самый ценный ресурс, я это осознал давно, более того – переключение между задачами просто выжигает мне мозг, по-этому я предпочитаю перекладывать рутинные операции на ПО и формализованные процедуры, чтобы их выполнение не занимало много интеллектуальных ресурсов.

Шаг 1: Research Ticket™

Записывайте все, что придет вам в голову! Мозг трейдера каждый день бомбардируется тяжелыми нейтронами в виде новостей, чатов, твиттеров, социальных сетей и прочих отвлекающих факторов, а идея – она приходит быстро и также быстро уходит, если вы не запишите ее на будущее то скорее всего через несколько месяцев придется все выдумывать снова, или вообще все забудется навсегда.
Раньше у меня был список идей в OneNote, потом я писал в блокнот, сейчас я пришел к формату Research Ticket™, тикет содержит в себе 3 раздела: данные, цель исследования и методика исследования.

  • Данные – это не только котировки базового актива, но вообще любые данные, которые будут использованы в исследовании. Это могут быть фундаментальные данные по компании, или календарь экономических новостей, или данные по смежным рынкам. Все это пишется в соответствующую графу.
  • Цель исследования – в этой графе можно описать к каким ожидаемым результатам мы планируем придти, также описываются разные интересные моменты, которые нужно исследовать поподробнее.
  • Методика исследования – примерный алгоритм действий как будет проистекать исследование, этот раздел очень важен, потому что нужно ставить перед собой много маленьких, и выполнимых задач-шагов, в противном случае ваш мозг может отказаться решать слишком расплывчатую задачу, и просто впадет в ступор :)
  • Итоги исследования – результаты исследования, после завершения работы, должны быть написаны с обратной стороны листа, в зависимости от результатов исследование идет дальше по фреймворку или отправляется в архив до лучших дней.

Research Ticket я предпочитаю писать от руки, а не печатать, так как во время работы на компьютере возникает много соблазнов и отвлекающих факторов, лучше налить хорошего чайку и в спокойной обстановке, чтобы никто не отвлекал, занести мысли в тикет. Потом новый тикет вешается на “прикол” на доску рядом с рабочим местом, и он всегда перед глазами, так и просит, чтобы его порисечили :)

Шаг 2: Exploration

Читать далее…

System Development Framework 2.0: Исследования теория

Сегодня мы поговорим об этапе System Development Framework 2.0 – исследованиях, я специально пропустил этап идей, потому что моя задача на сегодня разложить и систематизировать исследования в рамках моего фреймворка, к идеям мы вернемся позже. Сейчас самое время поговорить о том, что делать с идеями, потому что я встречал много трейдеров у которых было много идей, но мало сил и компетенции их развить и превратить в продукт. На самом деле путь от идеи до продукта, в нашем случае торговой системы, занимает очень много времени: идей много, на все времени не хватает, постоянно что-то отвлекает, в итоге все нарастает как снежный ком. Когда садишься на компьютер с желание что-нибудь сделать, возникает минимум 10 направлений приложения своего труда, не только исследования, но и технические проблемы. Да и вообще пока почитаешь новости, блоги, социальные сети – желание что-нибудь сделать, куда-то уходит.

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

Микрофреймворк в рамках System Development Framework 2.0

Нужно понимать, что процесс между этапами “Идея” и “Исследование” проходит не линейно, а часто какая-то идея циркулирует и наполняется новыми смыслами и деталями, до тех пор пока эта идея не станет максимально конкретной и формализуемой. Для примера можно взять несколько разных по уровню конкретики идей: “торговля опционами в Америке”, “как выход Non-Farm Payrolls влияет волатильность” или более конкретную “как действия ЦБ РФ влияют на Рубль, если за предыдущий день были максимальные валютные интервенции за месяц”. Как вы видите все три идеи отличаются разным уровнем проработки, отличаются разным уровнем глубины знаний о предмете. Читать далее…

System Development Framework 2.0: Этапы

Мой SysDev разделен на 5 этапов, три из них посвящены разработке торговой системы, и два этапа направленные на поддержание торгового процесса. Каждого этапа мы коснемся подробнее в дальнейших постах, а сейчас краткое описание всех этапов.

Этап 1: Идеи

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

Этап 2: Исследования

Когда у нас есть какая-то конкретная идея, можно начинать запускать механизм SysDev Framework. На этом этапе сырье в виде идеи, превращается в заготовку торговой системы – в исследование. Можно было бы перескочить этот шаг, и сразу начать писать правила торговых систем и тестировать их. Однако, я пришел к выводу, что такой путь неэффективен, так как очень легко быстро потеряться в дебрях нюансов, и в итоге когда вы сделаете торговую систему, может получиться так, что множество идей были забыты и не проверены. Это примерно как найти свой дом на Google Maps: сначала вы должны найти континент, потом страну, область, город и только потом улицу и дом. Быстро переключив масштаб карты с глобального на минимальный вы вряд ли сможете когда-то отыскать нужную точку на карте. Именно для этого нужен этап исследований, чтобы помимо глобального направления (идеи) мы смогли бы отыскать локальные области (но не точки) где может быть рыночная неэффективность.

Читать далее…

System Development Framework 2.0

Прошло более четырех лет с тех пор как я опубликовал свой первый пост про System Development Framework, и прошло более шести лет с тех пор как я прочитал ту самую ветку на EliteTrader, наверное пришло время собрать и проанализировать, как эволюционировал этот фреймворк в моей торговле, что изменилось, что работает и что нет.
Эти строки я пишу больше для того, чтобы систематизировать в своей голове знания и подходы, которые я выработал за последние 5 лет, надеюсь они смогут помочь другим трейдерам что-то улучшить в своей торговле. Сразу предупреждаю: не ждите готовых решений или предложений о покупке. Это всего лишь идеология, которая помогала мне последние годы выдирать профит у рынка, и спасаться от убытков, даже когда все летело в тартарары, когда одна за одной системы деградировали и умирали я не получал убытков к которым бы не был готов, все было в рамках расчетов.

Идеология System Development Framework

System Development Framework – это технология разработки, тестирования и исполнения торговых систем. Как в любом хорошем отлаженном бизнесе, где все бизнес процессы понятны и формализованы, в трейдинге тоже можно и нужно формализовать подходы, минимизировать человеческое вмешательство. В реальной жизни есть два подхода к производству: можно производить уникальный штучный товар под каждого клиента, а можно создать массовое производство и сделать много похожих продуктов, но временные и человеческие затраты на единицу продукции у массового производства несравнимо ниже, чем у аналогичного предприятия производящего уникальные продукты.
По пути массового производства иду и я со своим SysDev Framework, я не хватаю с неба звезд в плане понимания рынка и его участников, но я достаточно далеко продвинулся в этом. Тем не менее я постоянно работаю над тем, чтобы уменьшить свои трудозатраты на технические вещи (бэктестинг, исполнения трейдов, аудит, риск менеджмент), для того чтобы максимально сосредоточиться на понимании рынков, исследованиях рыночных неэффективностей, поиске интересных (не общедоступных) данных. Как только пришла идея, и она хоть как-то формализована, она подается на вход механизму, на выходе которого получается торговая система, готовая к торгам.

Читать далее…

Оценка ликвидности американских опционов CBOE

Давно не писал, чего-нибудь хардкорного, все ликбезы да ликбезы, но тут под руку подвернулась необходимость быстренько происследовать американский рынок опционов. Это исследование достаточно общее, и как мне кажется будет полезным для всех, кто интересуется американскими опционами, которые торгуются на опционной бирже CBOE. Попутно в этом посте я покажу несколько приемов работы с Python Pandas, который незаменим в случае когда нужно набросать какое-нибудь исследование на коленке, для трейдера Python Pandas является незаменимой вещью, более того я считаю, что Pandas в связке с IPython Notebook по гибкости и скорости разработки может дать фору любому языку программирования.

Почему американские опционы?

Бинарные опционы и опционы на РТС – это конечно хорошо, но если вы хотите стать профи в опционах, или вы оперируете суммой больше 100к долларов, вам потребуется ликвидность. И ни один рынок в мире не предоставляет такого набора базовых активов и ликвидности как американский, опционы там на любой вкус и цвет: хочешь недельные сроки – пожалуйста, хочешь на 3 года – пожалуйста. Более того, при наличии ETF перед инвестором и трейдером открывается весь мир, так как ETF есть практически на все мировые активы: индексы, золото, нефть, облигации и даже форекс! Для любителей российского рынка есть ETF RSX – Market Vectors Russia ETF, конечно ETF никогда не заменит базовый актив, и всегда будет присутствовать tracking error, зато вся торговля с одного брокерского счета у американского брокера. С другой стороны американский рынок – не сахар, это пожалуй, один из самых эффективных рынков в мире, не просто так многочисленные хедж-фонды зарабатывают себе на хлеб. Но я считаю, что до тех пор пока на вашем счете не будет десятка миллионов долларов, волноваться не стоит, и неэффективность всегда можно будет найти.
Читать далее…

Предохранитель торговых систем

Часто задаюсь вопросом: как формально определить что та или иная торговая система сломалась. Хочу поделиться некоторыми мыслями по этому поводу, и обсудить другие подходы к этой проблеме.

Первое что приходит мне в голову – это управление лимитом стратегии на основе анализа ее же equity. Основная идея такого подхода заключается в том, что в момент просадки по системе у нас срабатывал бы предохранитель, который консервирует стратегию или снижает ее лимит.
По такому случаю я написал пару простеньких скриптов в Амиброкере. Эта штука помогает быстро прикинуть качество того или иного алгоритма, я добавил 3 простых Equity стратегии: Parabolic SAR, EMA, и на основе Median.

Как оно работает:

1. В после теста Амиброкер создает тикер с названием ~~Equity
2. Накидываете оба скрипта на график и наглядно видите улучшились или ухудшились результаты при применении Equity стратегии.

Вот как это будет выглядеть:

31

Теперь немного отойдем от технических вещей, и поговорим о том что ближе к деньгам :)

Читать далее…

Новый-старый подход к оптимизации торговых систем

Размышляя над темой оптимизации систем, поймал себя на мысли, что популярная трейдерская парадигма тестирования In-Sample (IIS) и проверка на Out-Of-Sample(OOS) не лишена изъянов. В интервью Джеку Швагеру CIO хедж-фонда QIM Jaffray Woodriff раскритиковал этот подход, сказав что OOS это «cherry picking» результатов оптимизации, и по факту OOS является частью выборки IIS. Он предложил свое решение, которое изложено в его интервью в книге Hedge Fund Market Wizards. Но сегодня я хочу поговорить немного о другом подходе.

В тестировании в рамках парадигмы IIS-OOS, существует множество вопросов, Anchor например:

— Какой период отвести под IIS, какой под OOS и в каких пропорциях, 70/30, 50/50, 30/70?

— Какой период должен идти первым: IIS-OOS или OOS-IIS?

— В момент принятия решения, может возникнуть дилемма: а не изменился ли рынок, т.к. IIS и OOS у нас различаются.

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

Конечно во многих случаях проблемы выше можно решить с помощью walk-forward оптимизации, но для определенных типов стратегий/исследований этот подход не будет работать. Как например, для некоторых паттернов, которые либо есть, либо нет, как беременность ©. Такого рода паттерны тоже нужно проверять на прочность.

Больше всего меня лично в IIS-OOS подходе не устраивает, то что этот подход плодит дилемму «а не изменился ли рынок», и особенно в случаях когда IIS — это самые свежие данные, так и хочется подумать: OOS плохой потому-что рынок тогда давным давно был другим. Эта особенность мозга ломает все функции IIS-OOS по отбраковке подгонки.

Теперь к сути моего подхода, идея которого не нова, она знакома многим кто занимается data mining и machine learning как кросс-валидация, такую же идею в свое время выдвигал Kent .

Суть в том, что мы разбиваем наши данные не на 2 куска, а на 3, точнее 10 кусков по 3.

Куски будут иметь следующие функции:

1. In-Sample — критерий по которому будет проводится первичный отбор

2. Out-Of-Sample — критерий по которому будет проводится валидация IIS

3. xOOS — критерий по которому будет оцениваться «честный» performance системы

Как я разбиваю данные:

IIS — 25%

OOS — 25%

xOOS — 50%

Допустим выборка у нас 120 баров, мы делим ее на 10 кусков по 12 баров, с чередующимися IIS-OOS-xOOS.

Состав одного из кусков ниже, дальше повторяем такие блоки еще 10 раз, пока не заполним всю историю.

IIIOOOXXXXXX
I – InSample
O – OutOfSample
X – XOutOfSample
В пропорциях 25%/25%/50%

Как мы видим наши данные делятся пополам на 2 куска, один из которых участвует в анализе IIS-OOS, а другой исследуется на финальном этапе, как «честный» performance системы.

Теперь для отбора систем можно полноценно рассчитывать метрики на основе соотношений показателей IIS/OOS, при этом задействовав лишь 50% данных, а другие 50% использовать для общей валидации робастности оптимизационной выборки.

Проблема с изменением рыночных условий остается, но она уже не такая острая, т.к. мы используем все данные в IIS/OOS/xOOS, но редко встретишь системы которые хорошо работают на всех фазах рынка за 10 лет :) Думаю эту проблему нужно будет решать с помощью других методов, например понимания как и когда изменилась микроструктура рынка, и начинать тестирование с этого момента.

Disclaimer: никакая оптимизация не даст гарантии, что система будет работать в будущем, поэтому помимо статистики в рынку нужно прикладывать и голову, чтобы понимать процессы которые происходят на рынке.

Перенесено из: старого блога

Простой способ визуализации Edge

Многие задаются вопросом: что такое Edge торговой системы и как его померить. Еще в 2010 году я описал алгоритм EdgeTest’a на основе алгоритмов монте-карло. Но буквально вчера, просматривая один блог, я поймал себя на мысли, что автор изобрел простой и гениально эффективный EdgeTest.

В этом посте MarketSci описывает одну стратегию. Но суть не в стратегии, а в представлении графика Equity, где есть 2 варианта развития событий: прирост капитала в моменты удержания позы, и во все другие дни.

30

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

Перенесено из старого блога

Amibroker: несколько способов сварить странную систему и еще один рецепт

Weird Systems Cookbook

Адептам for-loop тестирования посвящается :)

Этот топик даст вам несколько путей создания торговых системы, которые можно оттестировать, и которые никогда не будут работать в реале так же как на тестах.

1. Системы входящие лимитными ордерами
Самая любимая тема. Идея проста как 2 пальца, берем некое среднее, откладываем от него вверх и вниз какой-то канал. Продаем когда цена (High) выше, по цене канала, и покупаем когда цена (Low) ниже нижней границы. Классический пример BollingerBands. В реале предполагается, что эта система работает лимитниками. Амиброкер эту стратегию прекрасно может оттестировать.

Но в риал-тайме вы никогда не получите сделки 1 в 1 с моделью, по следующим причинам:
– Нет гарантий исполнения лимитов (Амиброкер будет считать что 100% сделок исполнены)
– Вам на 100% будут наливать в худших сценариях, и часть самых нажористых сделок будет уходить
– Что делать если волатильность свечи такая, что H и L коснулись обеих границ канала?

2. Система торгующая на одном и том же баре
Что может быть проще: вошли по Open свечи, вышли по Close. Aх да, стопы не забудьте, на выходе грояль.
Один вопрос: а что первое срабатывает у этой weird системы стоп или профит? Ами не знает, я тоже :)

3. Система электросенс
Мои самые любимые грояли. Когда-то я входил на отрытии свечи, если RSI(20) превышал что-то. Все было хорошо, и миллиардный профит, и мечты о машине, квартире, и острове. Кроме риал тайма 😀 Только тогда мне было невдомек, что все встроенные индикаторы Ami используют Close для расчетов, тот самый Close который должен появиться после того самого Open на котором я открыл трейд.

Вы уже поняли, что векторные ништяки языка имеют в себе некоторые подводные камни – это издержки подхода. Есть event модель тестера, но там другие косяки, скорость тестирования на пару порядков ниже, и объем кода в 3-5 раз выше.

Anti-weird trading system

Чтобы избежать множество этих камней, я разработал несколько простых принципов построения системы:

  1. Самое главное: Входите в сделку только по Close, весь анализ стройте на основе Close – это избавит от заглядывания в будущее, в том числе скрытого как у “системы электросенс” и тестер станет прямым! Это относится только к цене входа, конечно же, OHLCV – можно использовать в анализе, а не только Close
  2. Избегайте торговать на одном баре
  3. Избегайте ставить близкие стопы/тейки, Ами не знает что у свечи было первым High или Low. Иначе перейдите на более мелкий фрейм, вплоть до тиков.

Все вместе это выливается в следующий шаблон кода:

//
// Author: ubertrader
// 24.09.2012
// </code>

// П.1: Запретить выход на том же баре что и вход
//
SetOption( "AllowSameBarExit", False);
//
// Если вы входите по Close, эту опцию нужно ставить False,
// иначе если H или L удовлетворяют условию стопа, он у вас сработает.
// Это заглядывание в прошлое - другой тип weird систем :)
//
SetOption( "ActivateStopsImmediately", False);

//
// Обратный сигнал активирует выход из открытой позиции
// ЗАПРЕЩЕНО! В моей парадигме - это так.
SetOption( "ReverseSignalForcesExit", False);

//
// Отключает задержки входа выхода
// В нашем случае они не нужны
SetTradeDelays(0,0,0,0);

//
// Сбрасываем настройки всех стопов, которые установлены в свойствах тестера.
// Стопы/Тейки/трейлинги - делаем все в коде, ставить их через GUI идиотизм 1999 года выпуска!
ApplyStop(stopTypeLoss, stopModeDisable, 1);
ApplyStop(stopTypeNBar, stopModeDisable, 1);
ApplyStop(stopTypeTrailing, stopModeDisable, 1);
ApplyStop(stopTypeProfit, stopModeDisable, 1);

//
// SAMPLE NON-WEIRD SYSTEM CODE
// Пусть это будет RSI

Buy = RSI(30) &gt; 70; //Покупаем когда RSI выше 70
Sell = C &lt; MA(C, 20); //Продаем когда цена ниже средней

Short = Cover = 0; //нэту шортов
//BuyPrice = SellPrice = Close; // -- это по умолчанию задается в настройках как Close и желательно ничего не менять

//
// Правила в том виде как они записаны, генерируют десятки или даже сотни повторяющихся
// на каждом баре сигналов. Тестер конечно приведет это в норму, но я привык к тому,
// чтобы мои сигналы на графике совпадали с тестером 1 в 1
// Equity(1, 0) - расставляет все сигналы точно также как это делал бы тестер
// Более того эта функция считает стопы и их цену - все это можно вывести на график.
Equity(1, 0);

//
// Финт ушами!
// Эквивалентно Buy at next bar Open
// Да, посчитали по Close и в самом конце перенесли на Open!
// Это позволит нормально торговать эту систему в RT.
//
Short=Ref(Short,-1);
Cover=Ref(Cover,-1);
Buy=Ref(Buy,-1);
Sell=Ref(Sell,-1);
BuyPrice= O;
SellPrice = O;
ShortPrice= O;
CoverPrice = O;

//
// И последнее стопы!
// Стопы только после того как перенесли все на Open, иначе будут считаться неправильно!
//
ApplyStop(stopTypeNBar, stopModeBars, 90); // Этот стоп можно использовать и до "финта ушами"
ApplyStop(stopTypeProfit, stopModePoint, 1000, 1);
ApplyStop(stopTypeLoss, stopModePoint, 500, 1);

//Чтобы на графике отразились и стопы!
Equity(1,0);

//
// Последнее рисуем цену и стрелочки входов/выходов
// Аргумент "-8" в PlotShapes() для того чтобы стрелка четко указывала на уровень (это смещение в пикселях)
Plot(Close,"",colorBlack,styleCandle);

PlotShapes((Buy > 0) * shapeUpArrow, colorGreen, 0, BuyPrice, -8);
PlotShapes((Sell > 0) * shapeDownArrow, colorRed, 0, SellPrice, -8);
PlotShapes((Cover > 0) * shapeHollowUpArrow, colorGreen, 0, CoverPrice, -8);
PlotShapes((Short > 0) * shapeHollowDownArrow, colorRed, 0, ShortPrice, -8);

Софт для трейдинга: свой или чужой

В свое время я перепробовал кучу софта, считал что мне нужен комбайн all-in-one, на котором я мог мы реализовывать свои идеи. Понятно, что идеального софта нет, и встал выбор либо писать свое, либо ставить костыли к Амиброкеру и изгаляться.

Сначала я был настроен писать свой софт, а потом прикинул: “А нафига мне городить огород ради одной задачи, которая может и не выстрелить? Лучше это время потратить на исследования.” В и тоге ограничился костылями, идея так и не выстрелила. В итоге вместо многих месяцев работы, я потратил пару дней, и больше к этой идее не возвращался.

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

Я под каждый тип задач, имею некий набор инструментов. При этом инструменты подобраны так, чтобы решать максимально эффективно свой круг задач. Эти задачи можно разделить на две категории:
1. Generic way – когда задача на 100% решается с помощью прог ТА
2. Custom way – когда задачу без костылей не решить, когда упираешься в непреодолимые ограничения архитектуры проги ТА.

Custom way – это не свой бэктестер или средства визуализации, а решение задачи за максимально короткий срок, с минимальными трудозатратами. Например, задача формирования данных, дальше импорт в прогу ТА или Excel и анализ в них. Такие задачи “на коленке” максимально эффективно решает Python. И Python менее эффективен в решении сугубо трейдерских задач, чем специализированные программы.

Вообще в последнее время я стараюсь выдавливать из себя программиста по капле, ведь мне за софт никто не платит, а дорабатывать софт можно до бесконечности. Более того у меня развилась аллергия на кодинг, особенно на C# :) Поэтому,как человек ценящий свое время, и повернутый на эффективности труда, я работаю по философии Quick & Dirty.

Правила Q&D:

  • Создать максимум бенефита за минимум времени
  • Если есть 2 пути решения проблемы, красивый и долгий, или быстрый и некрасивый – выбирай второй
  • Есть желание написать крутую прогу, напиши на коленке скрипт – это круче!
  • Если есть перспективное направление на которое нужно много времени, потрать немного времени на первое знакомство, и исследования в первом приближении

p.s. Python – идеально вписывается в Custom Way и в философию Quick & Dirty!