Избранное трейдера chuikapridi
Привет всем! В предыдущих статьях я описывал свой тестер, разработанный на C#, и, несколько раз подчёркивал, что переключение между двумя режимами (тестирование/торговля) может быть простым. Код стратегий не должен зависеть от того, кто поставщик маркет-даты и куда уходят заявки – в тестовую базу или на сервер брокера. Конечно, это лишь один из подходов, и кому-то он покажется странным, но, главное его достоинство заключается в том, что тестирование приближается к реальности, что даёт более достоверные результаты. Вопрос в следующем: как, имея один и тот же код, получать разные по функциональности программы? Один из вариантов – использовать инверсию управления и внедрение зависимостей! Об этом сегодня и пойдёт речь.
Приведу пример нехорошего (иногда, говорят – с запашком) кода:
class Strategy { public Strategy() { var mgr = new TestOrderManadger(); mgr.PlaceOrder(...); } }
Здесь плохо то, что класс Strategy зависит от класса TestOrderManadger. В такой реализации нельзя начать использовать какой-нибудь другой менеджер заявок (AnotherOrderManadger) без перекомпиляции библиотеки с классом Strategy. Тем более тут нарушается принцип единства ответственности – класс Strategy, помимо своей прямой обязанности, также, создаёт внутри себя зависимости. Чтобы исправить ситуацию, можно использовать интерфейсы:
interface IOrderMandger { void PlaceOrder(); } class TestOrderManadger : IOrderMandger { public void PlaceOrder(){} } class Strategy { public Strategy(IOrderMandger orderMandger) { var mgr = orderMandger; mgr.PlaceOrder(...); } }
Добрый день. В предыдущих частях я описывал, как на C# сделал собственный тестер, применяя объектно-ориентированный подход, рассказывал про интерфейсы, про их реализации, и, рассказывал про работу с БД. На данный момент осталось совсем немного. В этом топике я опишу вариант расчёта результатов работы стратегии.
Чтобы не запутаться, даже не читая предыдущие топики, поясню, что есть и к чему надо придти. Есть стратегии – это некий объект программы, который выставляет заявки на основе получаемой маркет-даты. Заявки (Order) регистрируются системой. Также, регистрируются сделки прошедшие по заявке (каждая заявка имеет список сделок — List<Trades> trades). После прогона стратегии, все заявки и сделки сохраняются в БД, и после, их можно извлечь и посчитать по ним статистику работы стратегии. По сути, эта статистика состоит из двух аспектов: сами закрытые позиции и оценка эффективности на их основе. Начнём с первого. Вот интерфейс, который принимает заявки со сделками, и, выдаёт, собственно, список закрытых позиций:
interface IClosePositionManager { List<ClosePosition> ClosePositions (List<Order> orders); }
Я пишу финансовые чипсы (novice_chips) для новичков, они пользуются вниманием, более сложный материал я излагаю в fin_chips (более 100 штук), торговые приемы и нюансы, к которым можно прийти за 3-5 лет торговли.
Сегодня я решил обнародовать свой первый practice_chip, открывающий серию из 70 практических нюансов, которые мы выводили на тренингах с постоянной группой.
ПРАКТИЧЕСКИЕ НЮАНСЫ ТОРГОВЛИ:
ИЗМЕНЕНИЕ СУММАРНОГО СПРОСА И ПРЕДЛОЖЕНИЯ КАК ПОДСКАЗКА О НАПРАВЛЕНИИ БУДУЩЕГО ДВИЖЕНИЯ И СМЕНЫ ТЕНДЕНЦИИ.
Изменение суммарного спроса и предложение (СиП) может выступать опережающим индикатором для интрадейщика, давая ему подсказку о том, в каком направлении планируется/готовится сдвиг по цене (на процент и более) в самое ближайшее время, стоит ли рассчитывать на продолжение явленной утром тенденции до конца дня, поставлены ли хай (вершина) и лой (дно) на этот день в акции и многое другое.
Данная подсказка не должна служить сама по себе причиной входа и выхода из позиции, но является важной частью внутридневного анализа, особенно в периоды, когда рынок находится в потенциально разворотных точках (на предполагаемой среднесрочной вершине или у локального дна).
– Привет! В предыдущий раз, ты рассказывал про дата-сервис, про отдельный слой доступа к данным. Расскажи теперь про сами сущности и репозитории. При помощь чего ты вытягиваешь данные из таблиц?
– Ок. Если необходимо сохранять сделки и статистику, или откуда-то брать исторические котировки для тестов, то неплохо использовать БД. Но, как с ней общаться? Есть несколько способов. В C#, есть например традиционный ADO.NET, но речь пойдёт не о нём. В прошлый раз мы отделили работу с БД от бизнес-логики, это уже очень здорово, но можно пойти дальше! Есть способ общаться с самой БД на достаточно абстрактном уровне, инкапсулируя детали формирования самих запросов. Такой способ лучше вписывается в концепцию объектно-ориентированного проектирования, и называется он ORM (object relation mapping).
– Хм, я что-то слышал про ORM. У меня сложилось неоднозначное ощущение, вроде, есть целое сообщество, кто против них (OrmHate), и считает это антипаттерном. Все эти дополнительные уровни абстракции, и вообще, они наверно дико тормозные?
Суть скрипта — отслеживать резкие изменения цены.
1. Создайте каталог c:\Qpile — в нем будем хранить старую цену.
Создайте подкаталог c:\Qpile\GO — в нем будем хранить пойманные шпильки.
При наличии шпильки(гэпа) в подкаталоге GO будет создан файл с названием этого фюьчерса, это может быть удобно для дальнейших действий, скажем, можно запускать по планировщику заданий фaйл check.bat, который будет проигрывать мелодию:
@rem check.bat
dir «c:\Qpile\GO» /a-d >nul 2>nul && (
@ECHO Поймали шпильку
%WINDIR%\Media\tada.wav
) || (
@ECHO Ничего не поймали
)
2. Посмотрите код текущих фьючерсов (в таблице фьючерсов добавьте колонку Код бумаги)
Отредактируйте коды инструментов, укажите коды актуальных фьючерсов:
sINSTRUMENT_BRENT=«BRV7» ' код инструмента BRENT
sINSTRUMENT_GOLD=«GDU7» ' код инструмента GOLD
sINSTRUMENT_EURUSD=«EDU7» ' код инструмента EUR/USD
3. Настройте при каких параметрах выводить сообщения о шпильках
'Процент изменения цены при которой выводится оповещение:
sPrc_BRENT = 0.5
sPrc_GOLD = 0.2
sPrc_EURUSD = 0.4
4. Установите задержку обновления цены.
' Задержка:
NEW_GLOBAL(«sDELAY», 5)
(если при запуске скрипта стоит период расчета 10 сек. то значение 5 будет соответствовать примерно минуте).
Что то велосипедно-похожее иногда происходит и в нашем «опционном» мире. Я собираюсь сейчас прокомментировать несколько опционных
мнений-фокусов, вполне безобидных в текущей ситуации, но опасных при наступлении катастрофически-волатильных событий по типу «чучхэ понад усе».
Предварительные условия — обсуждается исключительно опционный рынок forts, ставки ноль.
Фокус первый.
Бытует мнение: распределение цен БА на момент экспирации, порождаемое ценами опционов, предполагает одинаковые вероятности смещения цен БА вверх или вниз.
Источник: интернеты, комментарии в них, и, увы((, Стас Бржозовский тут: https://smart-lab.ru/blog/411878.php
Факт: это полная ерунда. На самом деле, если допустить справедливость формулы Блэка для опционных цен (при условии постоянной волатильности на всех страйках), мы получим, что вероятность снижения цен на момент экспирации всегда выше, чем вероятность их роста.
Доказательство: берем и считаем в лоб. Например, при волатильности 50 и сроке до экспирации 1 год, вероятность снижения цены на момент экспирации составит 0,6. При волатильности 200, допустимой при катастрофах, ситуация будет еще интереснее. Правда в том, что матожидание распределения, порождаемого ценами опционов, совпадает с ценой БА в каждый момент. Но мало кто замечает подмену понятий и задумывается об этом.
Фокус второй.
Бытует мнение: дельта опциона колл на центральном страйке по модулю обязана совпадать с дельтой опциона пут и равняться 0,5.
Источник: многочисленные русскоязычные сайты, отдельные персонажи Смартлаба, тупые переводчики с английского на русский язык.
Факт — это вранье. Многие «канонические» авторы (Конноли, Натенберг, Мак-Миллан) действительно пишут, что дельта центрального колла ПРИМЕРНО совпадает по модулю с дельтой пута. И это правда, при низкой волатильности и малом времени до экспирации. Однако, при росте любого из этих двух показателей ситуация меняется кардинально.
Доказательство: все очень просто. Дельта центрального опциона колл (модель БШ) равна N(d1), d1>0, следовательно дельта центрального опциона колл в мире БШ всегда больше 0,5 и возрастает как с ростом iv, так и с ростом времени до экспирации. В предельном случае при бесконечной волатильности и/или времени до экспирации дельта центрального опциона колл — единица. Где живут риски неправильной оценки дельты? Сегодня — в Тихом океане. И если неистовый Ким попробует бабахнуть по душке-Дональду, то дельты опционов центральных страйков удивят многих. Пример: дельта центрального опцина колл при волатильности 50 и сроке до экспирации 1 год составляет 0,6. Каждый может в этом убедиться при помощи любого опционного калькулятора, живущего в интернетах.
Фокус третий.
Бытует мнение: вероятность выхода в деньги опциона колл совпадает с его дельтой.
Источник: интернеты и прочие сомнительные места.
Факт — это вранье дважды.
Доказательство: см первые два фокуса. Пример: вероятность выхода центрального опциона колл «в деньги» при сроке до экспирации 1 год и влатильности 50 составляет 0,4. Дельта 0,6.
Можно еще, наверное, пофокусничать с общепринятыми мнениями, но пора откланяться
PS
/М.А. Булгаков/:
«А может быть, не было никаких этих слов, а были другие на эту же музыку, какие-то неприличные крайне. Важно не это, а важно то, что в Варьете после всего этого началось что-то вроде столпотворения вавилонского.»
В прошлый раз мы проверили трендовую природу индикатора RSI. Нами были получены интересные результаты, особенно при торговле основными секторами. В этот раз мы продолжим двигаться в направлении изменения индикатора RSI, но будем использовать сигнал разворота тенденции.
Рассмотрим пересечение индикаторов RSI разных периодов. Алгоритмы пишем в Quantopian на Python.
В этот раз: