статьи. StockSharp

Tорговые роботы. Full Orders Log.

2012-03-13T14:36:51Z

Здравствуйте. В этой статье мы расскажем Вам, что такое Full orders log, как он выглядит, для чего используется, и какую интересную информацию можно в нем увидеть. Начнем с определения и общих понятий и свойств. После этого поговорим о том, как можно использовать ордер лог для создания торговых роботов.
Full orders log (в статье будем использовать сокращение FOL) — это список всех заявок с полной информацией по каждой заявке. Еще его называют анонимным ордер логом (анонимная рыночная информация), т.к. из всей информации о заявке в нем не доступен только номер счета клиента, пославшую эту заявку. Как вы понимаете, эта информация конфиденциальна. Ордер лог, это самый глубокий и детальный уровень информации, который доступен трейдеру.

Полный список полей таблицы orders_log

Поле Тип Описание

replID i8 Служебное поле подсистемы репликации

replRev i8 Служебное поле подсистемы репликации

replAct i8 Служебное поле подсистемы репликации

id_ord i8 Номер заявки

sess_id i4 Идентификатор торговой сессии

client_code c7 Код клиента

moment t Время изменения состояния заявки

status i4 Статус заявки

action i1 Действие с заявкой

isin_id i4 Уникальный числовой идентификатор инструмента

dir i1 Направление

price d16.5 Цена

amount i4 Количество в операции

amount_rest i4 Оставшееся количество в заявке

comment c20 Комментарий трейдера

hedge i1 Признак хеджевой заявки

trust i1 Признак заявки доверительного управления

ext_id i4 Внешний номер

login_from c20 Логин пользователя, поставившего заявку

broker_to c7 Код FORTS фирмы-адресата внесистемной заявки

broker_to_rts c7 Код RTS фирмы-адресата внесистемной заявки

date_exp t Дата истечения заявки

id_ord1 i8 Номер первой заявки

broker_from_rts c7 Код РТС клиента — владельца заявки

id_deal i8 Идентификатор сделки по данной записи журнала заявок

deal_price d16.5 Цена заключенной сделки

local_stamp t Локальное время пользователя

Онлайн данные по full_orders_log можно получать через шлюз Plaza2. До 17 февраля 2012 года по Plaza2 была доступна информация только по рынку ФОРТС, с 17 февраля Биржа ММВБ – РТС начала трансляцию анонимной рыночной информации по Валютному рынку и Фондовому рынку в секторе Основной рынок.
Таким образом, через шлюз Plaza II будет доступна информация по следующим рынкам:

Cрочный рынок FORTS
Фондовый рынок в Секторе рынка Standard
Валютный рынок в режиме РТС Money
Фондовый рынок в Секторе Основной рынок

Сохранять ордер лог, обрабатывать и создавать торговых роботов на его основе, вы можете с помощью библиотеки StockSharp. 11 марта StockSharp был сертифицирован биржей РТС для работы с Plaza II.

Файл с сохраненными данными FOL выглядит примерно следующим образом. Вид из FAR'a.
Tорговые роботы. Full Orders Log Рис.1

Формат данных может немного различаться, зависит от настроек программы, через которую вы его получаете, которая может трансформировать данные, для приведения их к более удобному виду. Например, в изначальном варианте инструменты обозначаются с помощью isin_id i4 Уникальный числовой идентификатор инструмента (8й столбец на картинке) Помимо ордер лога, по шлюзу Plaza2 передается и другая информация, среди которой fut_sess_contents, где мы можем посмотреть соответствие числовых идентификаторов названию контактов. Например, isin_id = 242176 будет соответствовать контракту RIH2. Таким образом, мы можем преобразовывать вид данных. В этой статье Вы столкнетесь с картинками, где они будут немного различаться.

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

Symbol – название инструмента = isin_id

Type – покупка/продажа = dir

ID - уникальный номер заявки = id_ord

Moment - время изменения состояния заявки = moment

Volume – количество лотов = amount

Price – цены по которой выставляли заявку = price

Action Действие с заявкой - выставление 1/удаление 0 /сделка 2 = action

ID_Deal - уникальный номер сделки = id_deal

Price_Deal – цена по которой прошла сделка = deal_price

В отформатированном виде ордер лог будет выглядеть примерно так.
Tорговые роботы. Full Orders Log Рис.2

Как хранить и обрабатывать FOL

На данный момент (2012 год), файл с ордер логом с данными по всем инструментам срочного рынка весит порядка 4-5 гигабайт за один торговый день. По инструменту RTSi, порядка 1 гигабайта за один день. В одном дне RTSi содержится порядка 8-10 млн строк, из них сделок 600-800 тысяч строк.
1 гигабайт или 9млн строк за день, довольно внушительный объем данных. Поэтому появляется вопрос, как лучше работать с таким объемом данных? По сути, оредр лог представляет собой базу данных, поэтому для его обработки и хранения можно использовать программы для создания и хранения БД. С помощью языка SQL мы можем обрабатывать данные, выводить нужные нам информация и производить расчеты. SQL проще чем C#, т.к. имеет узкую специализацию, поэтому его легче освоить, но использовать его для других целей проблематично. Писать робота нужно на C#, для вспомогательных целей при работе с ордер логом использовать SQL.

Торговые роботы на основе ордер лога.

Как уже было сказано, создавать торговых роботов на основе ордер лог можно с помощью stocksharp.
Plaza2 + FOL дают высокую скорость и все необходимые данные для создания и работы высокочастотных роботов. Тут и добавить больше нечего, бери да делай. Если же говорить о тестировании высокочастотных роботов на истории, то нам необходимы стаканы и все сделки. И стаканы и сделки можно сохранять отдельно от FOL через другие каналы. Но, стаканы и сделки не синхронизированы, т.е. мы можем получить такую ситуацию, когда те или другие данные пришли с запаздыванием, в итоге сделка будет относиться к стакану, который был несколькими секундами ранее или позднее. Например, при стакане с офером на 160 600 проходит сделка на покупку 160 700. Ордер лог может избавить нас от такой проблемы, с его помощью можно получить синхронизированный со сделками стакан.
Еще такой момент по тестированию. Если вы захотите ознакомиться с FOL, вы можете скачать месяц бесплатной истории на сайте РТС. На Рис.2 как раз пример исторических данных с сайта РТС. Там вы можете увидеть момент времени, когда заявка пришла в систему, но! Когда заявка пришла к вам на компьютер, там не показано. Нам же, для формирования стаканов, нужно знать какими пачками и в какое время мы получали данные. Поэтому, когда мы сохраняем информацию на домашних компьютерах, дополнительно появляется метка времени, когда заявки дошли до нас.

Tорговые роботы. Full Orders Log Рис. 3
Добавлена метка с временем получения данных на компьютер

На сайте РТС, история ордер лога за один год по всем инструментам стоит 5000$. Если вам интересно это направление, стоит задуматься о сохранении истории уже с сегодняшнего дня, чтобы потом не тратить деньги на покупку.

Манипулирование биржевым стаканом: Торговые роботы или …?

Понимание рыночного механизма потока заявок может дать нам ответ на многие вопросы, правда после которых, может появиться еще больше количество вопросов. В сети лежит ролик “Манипулирование ценой в биржевом стакане”. В ролике показано, как трейдер выставляет заявку на покупку по цене лучшего офера в стакане. Как только он нажимает на ОК, оффер исчезает из стакана. Инсайдер (трейдер-блогер) объясняет такое поведение действиями торговых роботов.
Цитата: “Вы же наверняка часто видели, как кидая заявку на продажу по рынку, цена уходит назад и Ваша заявка удовлетворяется по цене ниже пунктов на 50, чем та цена, которую Вы видели секунду назад и цена сразу же возвращается назад на 50 пунктов вверх.

… Они видят благодаря РТС все Ваши манипуляции с заявкой и используют свои быстрые каналы связи с серверами биржи, чтобы откусить чуток от Вашего ордера.”
С точки зрения ордер лога, такого быть не может и торговые роботы не могут реагировать на такую заявку. Среагировать на поступившую заявку, мы можем после того, как к нам пришли данные из плазы. Это самый быстрый, легально возможный способ. Данные, пришедшие из плазы, это уже история, свершившееся событие. Значит, если мы кинули заявку по цене офера, то она обязана исполниться. Или, этот офер должен быть снят до того момента, когда наша заявка на покупку пришла в систему. Единственное объяснение, которое приходит мне в голову такое: брокер делает искусственную задержку и передает информацию о том, что идет заявка. После этого робот брокера отзывает свою заявку или делает другие нужные действия, после чего заявку клиента посылают на рынок. Достаточно задержать заявку на полсекунды, чтобы проводить такие махинации, что естественно незаконно. В законе о проф. участниках указанно, что в случае конфликта интересов брокера и клиента, брокер обязан отдавать приоритет клиенту. Так это происходит в действительности или нет, мы не знаем.

Ордер лог представляется интересным инструментом для анализа рыночной ситуации. Огромное количество интересных возможностей, о которых мы не сказали или даже не знаем. Если у вас есть вопросы, или нужна помощь по ордер логу, можете написать на почту info@stocksharp.com.

StockSharp Торговые роботы

Colocation преодолевает скорость света. 3 часть

2015-07-11T13:07:28Z

Перейти к части 2

Colocation обеспечивает лучшее решение для высокоскоростных приложений
Мы показали, что механизм центрального компьютера может быть заменен на функционально идентичный механизм с использованием группы компьютеров, размещенных с серверами биржи. Парадоксально, но в целях достижения эквивалентного результата мы должны были использовать абсурдные на первый взгляд генераторы искусственных задержек, что тормозило передачу информации от каждого сервера к компьютеру на задержку равную задержке полного круга между сервером и центральным компьютером – d (плюс дополнительная задержка сервера в общем механизме, совмещенных групп). Для большинства алгоритмов "центрального компьютера" удаление генераторов задержки в похожем сценарии позволит дизайнерам разработать алгоритм распределения, который не только соответствует, но гораздо лучше, чем алгоритм "центрального компьютера". Природа и значение улучшения будет зависеть от алгоритма и его функции. В большинстве случаев, алгоритм "центрального компьютера" придется переписать с нуля, чтобы воспользоваться преимуществом предвидения на местном рынке. (Однако, в некоторых случаях, улучшение невозможно. Рассмотрим это на примере неких ежечасных "слепых" аукционов. В таком случае, использование одного центрального компьютера будет оптимальным. То есть более экономичным, чем в группе совмещенных компьютеров.).
Вспомним наш пример "Нью-Йорк-Лондон" из предыдущего раздела. Что было бы, если бы замедлили передачу информации в дата-центре Нью-Йоркской биржи с коэффициентом 10 000 (с типичных двух микросекунд до 20 миллисекунд). Ни один уважающий себя высокочастотный трейдер не станет мириться с таким положением вещей. Удаление генератора задержки позволило бы размещенным компьютерам "заглянуть в будущее на локальных рынках" по сравнению с тем, что видит центральный компьютер. Это позволило бы развить значительное превосходство торговой стратегии. Фирмы, занимающиеся высокочастотной торговлей готовы платить миллионы долларов в месяц, чтобы увидеть 20 мс. в будущем. Другими словами, если компьютер находится в середине между финансовыми биржами, то это лучший способ приблизиться к скорости света, а с помощью компьютеров, размещенным в дата-центрах разных бирж можно "преодолеть скорость света" - откуда и название этой статьи.
Но даже и без каких-либо дополнительных усовершенствований, стратегии на механизме совмещенных групп должны быть развернуты только в N финансовых центрах по всему миру, а не n⋅ (N-1) / 2 "серединных торговых точек", показанные в статье Nature. Наконец, самая хорошая новость: нам никогда не понадобятся страшные "корабли для высокоскоростной торговли"!

Вариант полноценного Colocation решения может эмулировать любое другое решение
Мы показали, что механизм "центрального компьютера" может быть всегда заменен на функционально эквивалентный механизм или более эффективный, при использовании группы компьютеров, размещенных в дата-центрах бирж. Один вопрос, который остается: может ли быть улучшено данное решение? Можем ли мы, добавив несколько дополнительных компьютеров в середине и/или удалив некоторые из размещенных компьютеров, получить любое лучшее решение, чем то, которое может быть реализовано с помощью механизма "совмещенных групп"? Ответ: - нет. Полная группа N компьютеров совместного размещения с серверами N обеспечивает оптимальную конфигурацию, которая не может быть улучшена.
Для того, чтобы заявить об этом официально, мы определяем новый термин: "агрегирующая конструкция". Агрегирующая конструкция - это группа компьютеров, работающих под распределенным алгоритмом, включая каналы коммуникации между членами группы и все входные и выходные каналы связи с внешним миром (состоящая из "серверов"). В отличие от одного компьютера под управлением алгоритма, спецификация агрегирующей конструкции должна включать сведения, касающиеся пространственных расположений входов и выходов, а также компьютеров-членов, и задержки ограничений на связи между этими местами. Агрегирующая конструкция более официальный термин для того, что мы называли "черный ящик" в предыдущих разделах.
Данные N серверов, полноценного colocation решения агрегирующей конструкции – это объединение N компьютеров, совмещенных с соответствующими им серверами.
В заключении, чтобы продолжить наше доказательство, нам нужно будет провести операцию по "объединению" компьютеров. Если C1 и C2 два отдельных, совмещенных компьютера под управлением алгоритма A1 и A2, соответственно, то C1^C2 обозначает компьютер, на котором запущены те же алгоритмы и используются в сочетании входящих/исходящих каналов обоих компьютеров как входящих / исходящих каналов одного объединенного компьютера, соответственно (см. рисунок - "Операция по созданию объединенного компьютера C1 ^ C2"). Операция соединения является чисто косметической. Два алгоритма работают независимо друг от друга на объединённом компьютере и сохраняют все их свойства (например, смещение времени, входные задержки и т.д.). Сообщения, полученные и отправленные от двух алгоритмов, также остаются прежними. Операция по объединению позволяет рассматривать два размещенных компьютера, как один компьютер, который функционально эквивалентен обоим, будучи объединенными. От перестановки компьютеров суть операционного объединяющего компьютера не изменится. (В соответствии с правилами commutative и associative.).

Теперь мы готовы сформулировать и доказать основной результат.
Следствие 1. Любое объединение компьютеров, подключенных к нескольким серверам, может быть повторно реализовано с использованием полноценного colocation решения агрегирующей конструкции таким образом, что поведение агрегирующей конструкции (как зафиксировано серверами) неотличимо от исходной совокупности.
Для доказательства используем метод математической индукции (mathematical induction ) по числу K компьютеров совокупности, которые не совмещены ни с одним из серверов.
Очевидно, что вывод верен для К = 0. Здесь каждый компьютер агрегирующей конструкции находится в colocation связке с одним из серверов. Для того, чтобы сформировать эквивалент полноценного colocation решения агрегирующей конструкции, мы добавляем компьютеры, не совершающие никаких действий, к серверам, у которых нет подключенных компьютеров, и мы заменяем все компьютеры, находящиеся в colocation связке с данным сервером на их Joined версию (см. рисунок выше), чтобы обеспечить единый объединенный объект на каждый сервер.
Предположим теперь, что следствие верно для некоторого K ≥ 0.
Рассмотрим агрегирующую конструкцию D* подключённую к N-серверам (X1, ..., Xn), так чтобы K+1 компьютеров, которые не находятся в colocation связке ни с одним из серверов.
Мы начинаем с нормализации D*: добавляем компьютеры, не совершающие никаких действий, к серверам, у которых не было подключенных компьютеров D*, и мы заменяем все агрегирующие конструкции, находящиеся в colocation связке с данным сервером на Joined версию (см. рисунок выше), чтобы обеспечить единый объединенный объект на каждый сервер. Это не меняет количество, не находящихся в colocation связке компьютеров D* или поведение агрегирующей конструкции.
Отныне, мы предполагаем, что Di является одним из компьютеров D*, находящийся в colocation связи с сервером Xi для i = 1, ..., N. и что компьютеры DN+1, ..., DN+K+1, не находятся в colocation связи ни с одним из серверов.
Таким образом, мы предполагаем, что объект DN+K+1 не связан напрямую с любым сервером Xi. Если он был подключен непосредственно к Xi, мы всегда можем поручить компьютерам, находящимся в Colocation связке c Di стать сквозным посредником между Xi и DN+K+1.
Рассмотрим теперь все D1, …, DN+K компьютеры, как "серверы" в теореме 1. Пусть C = DN+K+1 будет центральным компьютером связующим с "серверами" D1, …, DN+K. По теореме 1, мы можем построить функционально идентичную систему, которая заменяет C на N+K компьютеров Xi, размещенным с соответствующими компьютерами Di.
Наконец, определим новую агрегирующую конструкцию E* работающую на компьютерах E1, …, EN+K, где мы устанавливаем Ei = Ci ^ Di..
Очевидно, что агрегирующую конструкции E* - это эквивалент D* (когда под присмотром серверов Xi), но имеет только К участников, которые не находятся в colocation связи ни с одним из серверов. Таким образом, по методу индукции, E* является эквивалентом полноценного colocation решения агрегирующей конструкции. Это завершает (предыдущий) шаг и доказывает следствие.
Примечание: Доказательство данного следствия может рассматриваться как предоставление метода, который позволяет удалить один за одним в любой последовательности не связанные colocation связью участников совокупности D* без изменения функциональности агрегирующей конструкции (как это зафиксировано серверами).

Colocation предоставляет оптимальное решение
Рассуждая об "оптимальности" мы можем только предположить, что пользователь имеет в виду измеримую меру полезности, которую можно будет применить к любой совокупности агрегирующих конструкций с определенным набором серверов. Мы предполагаем, что функция "полезности" может базироваться только на данных, полученных с серверов. (Например, можно было бы оценить торговую стратегию по ее средним дневным результатам на основе некоторого эталона, используя исторические исходные данные, собранные серверами). Теперь мы можем перефразировать Следствие 1 и констатировать, что:
Следствие 2. Полноценное colocation решение агрегирующей конструкции является оптимальным вариантом для HFT арбитражеров. Другими словами, нераспределенный алгоритм может обойти другие алгоритмы, используя агрегирующую конструкцию и colocation связку с серверами бирж.
Примечание: в итоге, в высшей степени важно учитывать нашу ненавязчивую позицию в определение того, что является "лучшими" средствами. Независимо от того, как вы оцениваете работу вашего алгоритма (например, желаете ли вы заработать или потерять больше денег), вы не можете обогнать распределённый вариант описанный выше. В качестве примера: Не начинайте интервенцию йены, если не находитесь в Токио (а также если не находитесь в Лондоне, если на то пошло)!

Реверсивные роли – распределенные биржи преодолевают скорость света
До сих пор мы рассматривали теорему 1 в сценариях, состоящих из торгового компьютера, подключенного к серверам нескольких бирж, потому что это схема укладывается в сценарий "серединной точки" из статьи журнала Nature. Теперь мы переформулируем теорему 1, поменяв местами роли бирж и финансовых центров.
Традиционные биржи располагают центральным matching (мэтчинг/матчинг) движком для компьютеров клиентов HFT, размещенным в одном центре обработки данных. Удаленные клиенты могут находиться по всему миру, используя компьютеры, расположенные в точке доступа дата-центров (либо самой биржи, либо сторонних компаний), которые предлагают безопасное, надежное и естественно с малой задержкой подключение к центральной системе (ядру биржи).
Рассмотрим теперь мэтчинговый движкок бирж как “центральный компьютер” и точку доступа в дата-центры, как "серверы", приведенные в теореме 1. Используя эту хитрость, теорема 1 может быть сформулирована следующим образом:
Следствие 3. Любой центральный мэтчинговый движок биржи подключенный к N ≥ 1 точки доступа дата центров может быть воспроизведен с использованием группы N соединенных между собой мэтчинговых движков, которые находятся в соответствующих дата-центрах таким образом, что поведение новой реализации (как зафиксировано в дата-центрах) ничем не отличается от оригинального решения на одном мэтчинговом движке.
В результате, следствия 1 и 2, могут быть преобразованы таким же образом. В частности архитектура биржи, которая использует полноценное colocation решение агрегирующей конструкции мэтчинговых движков (один мэтчинговый движок на каждую точку доступа дата центра) является оптимальной!

Кейс для распределенных бирж
Очевидно, что участники, торгующие HFT алгоритмы, давно выяснили преимущества colocation, когда торгуют арбитраж AAPL между различными серверами бирж Нью-Джерси, или когда торгуют арбитраж E-Mini на CME в Aurora, IL versus SPY, Arca в Secaucus NJ. Так почему же биржи упорно используют центральные мэтчинговые движки?
Основной причиной является производительность и прибыль биржи. По сравнению с одним центральным биржевым компьютером, распределенная биржевая архитектура добавляет проблем с точки зрения дизайна и сложности устройства, увеличивает задержки сделки, а также дополнительные затраты на инфраструктуру. Эти эффекты могут ощутить на своем опыте все клиенты биржи, даже те, которые не участвуют в арбитражных операциях и рады торговать в одном месте совместного размещения с простым, быстрым и относительно недорогим центральным мэтчинговым движком. Распределенная архитектура биржи также будет способствовать снижению (или сведет на нет) необходимость арбитража, что в результате снизит огромные объемы торговли арбитражеров, которые приносят пользу бирже.
На фондовом рынке США, торговля географически сосредоточена в одном месте. Начиная с NYSE и Nasdaq, практически все фондовые торги в США осуществляются на серверах в Нью-Джерси, которые находятся в нескольких десятках километров друг от друга. Несмотря на то что (благодаря 1998 SEC Regulation ATS) одна и та же акция может торговаться на нескольких биржах, каждая биржа, как правило, имеет только один мэтчинговый движок для данного эмитента. Несмотря на все это еще можно было утверждать, что, в целом, американский рынок акций использует распределенную мэтчинговую архитектуру:
1. Акции биржи и ATS (альтернативные торговые системы) требуют отправки заявок на разные площадки, чтобы получить лучшую цену (благодаря 2007 SEC регулирования NMS).
2. Распределители для умных заявок расположенные в точках доступа отправляют заявку на ту биржу, где заявка имеет наибольшие шансы пройти по лучшей цене.
3. Брокер/банк, выполняющие внутренние внебиржевые сделки и "дарк пулы" можно рассматривать как расширение основного мэтчингового механизма биржи.
Конечно, дьявол кроется в деталях и если посмотреть внимательно, то существующая биржевая архитектура Фондового рынка США (если рассматривать в совокупности как единый механизм) является чудовищно сложной и неэффективной. Компьютеры HFT трейдеров, имеющие colocation связку с несколькими ближайшими биржами процветают, торгуя арбитраж и другие интеллектуальные методы, эксплуатирования неэффективностей.
На рынках акций, опционов и фьючерсов, в силу исторических причин, восходящих к торговле фьючерсами на кукурузу или пшеницу, большинство американских фондовых фьючерсов и опционов торгуются в Чикаго (на CME и CBOE, соответственно). Здесь логично было бы просто переместить мэтчинговые движки CME и CBOE в Нью-Джерси. Но это вряд ли произойдет, учитывая, что пока еще нет конкурентного давления на биржи Чикаго, которое мотивировало бы их на этот шаг. Высокочастотные трейдеры этому только рады и конкурируют друг с другом, чтобы построить лучше дешевле, быстрее, распределенные арбитражные стратегии (используя Spread Networks tunnel и its true-speed-of-light successors[9]).

Поистине распределенная архитектура биржи
Наконец, давайте зададим обратный вопрос: почему и где были бы полезны распределенные биржевые серверы мэтчинга заявок для конкретного инструмента в отдалении от самих бирж? Первый ответ в том, что распределение биржевых серверов в пространстве было бы полезно, если клиенты были бы географически "рассредоточены" и не желали заказывать colocation своих торговых компьютеров с центральным мэтчинговым движком биржи.
До сих пор, единственная область, где распределенная биржевая архитектура нашла свое применение - это торговля на рынке Forex. Например, когда вы торгуете USD (доллар США) против JPY (Японская иены), необходима локальная информация о состоянии экономики каждой из двух далеко расположенных стран. Кроме того, есть политические аргументы против торговли своей валютой с помощью мэтчинговых движков далеко за рубежом.
Когда впервые была представлена электронная заявка на спот рынке Forex, что впервые произошло в 1990-х годах, были первоначально две USD/JPY биржи: Reuters (в Лондоне) и Майнекс (в Токио). Лондон - Токио задержки в те дни были порядка 300 мс, которые легко заметны невооруженным глазом. Также, были политические причины против торговли свей валютой на зарубежных площадках.
Когда мне была поставлена задача разработки новой глобальной биржи EBS Forex exchange, я выбрал распределенную архитектуру с тремя синхронизированными мэтчинговыми движками - в Лондоне, Нью-Йорке и Токио[10]. Это при условии отличной производительности во всех трех регионах и удовлетворении требований мировых банков. В 1996, EBS вошла в состав Minex, став доминирующей мировой USD/JPY площадкой на межбанковском электронном рынке - позиция, которую она занимает и по сей день. (Хотелось бы мне в то время обладать информацией из этой статьи, иметь представление о данной работе, когда пытался убедить своих коллег поверить в распределенную архитектуру бирж... но, в конце концов, мы использовали наше шестое чувство -, - и оказались правы)
Другой пример распределенной Forex площадки является Fastmatch, которая также имеет три мэтчинговых движка: в Лондоне, Нью-Йорке и Токио. Ее архитектура значительно отличается от EBS, однако, заявки распространяются не прозрачным способом и мэтчинг осуществляется по трем регионам.

Литература по данной тематике
Чтобы узнать больше о чудесах распределенных торговых систем, исследуйте ссылки [11] и [12] .

Благодарности автора
Я благодарю Michael Merold, Schalk Steyn, Alec Schmidt, Mark Reece, Wlodek Stankiewicz, Ewa Howorka, и всех, кто предоставили полезные комментарии по первоначальному проекту этого документа.

Ссылки
1. Mark Buchanan, Physics in finance: Trading at the speed of light, Nature, Feb 11, 2015.
2. A. D. Wissner-Gross and C. E. Freer, Relativistic statistical arbitrage, Physical Review E 82, Nov 5, 2010.
3. World Federation of Exchanges, WFE 2009 Annual report and statistics, Dec 2009.
4. Stock Trades at the Speed of Light, PhysicsCentral, Nov 11, 2010.
5. Eric Garcia, Physicist says it is possible to use ships to facilitate high-frequency trading, MarketWatch, Feb 19, 2015.
6. M. Rohan, Dark pool and HFT: It is possible to use ships for high-frequency trading, International Business Times, Feb 19, 2015.
7. Timothy B. Murray, HFT’s Oceanic Moment, WatersTechnology, Mar 11, 2015.
8. M. Rohan, Dark pool and HFT: BoE says high-speed trading helps markets, International Business Times, Feb 24, 2015.
9. Scott Patterson, High-Speed Stock Traders Turn to Laser Beams, Wall Street Journal, Feb 11, 2014.
10. Michael Togher, Michael F. Dunne, Richard Hartheimer, Credit management for electronic brokerage system, U.S. Patent No. 5,375,055, issued Dec 20, 1994, assigned to EBS.
11. Edward R. Howorka, Andrew P. Foray, Architecture for anonymous trading system, U.S. Patent No. 7,184,982, issued Feb 27, 2007, assigned to EBS.
12. Edward R. Howorka, Method and apparatus for enhancing market data feed using proprietary order flow, U.S. Patent No. 8,296,217, issued Oct 23, 2012, assigned to MarketFactory.
13. Edward Howorka, In brief, colocation beats the speed of light, The Trading Mesh, Apr 9, 2015.

Ссылка на первоисточник данной статьи
Перевод: Николай Флёров

Colocation преодолевает скорость света. 2 часть

2015-07-06T00:08:22Z

Перейти к части 1

В данной части мы подробно рассмотрим арбитражные механизмы на базе центрального компьютера и механизмы с применением Colocation. А также разберем конкретный алгоритм арбитражной стратегии в действии.

Механизм с применением центрального компьютера
Во-первых, давайте определимся с формально базовым "механизмом централизованного компьютера". Обратите внимание, что это гораздо более распространённое решение, чем сценарии "средней точки", рассматриваемой в статье Бьюкенена.
Рассмотрим N серверов X1, ..., Xn и центральный компьютер С может располагаться где угодно в мире на нем работает алгоритм А (например, торговая стратегия). С подключением ко всем серверам - он получает входные сигналы от респондентов и дает обратную связь каждому из них. Мы считаем, что этот механизм напоминает "черный ящик", где входные и выходные данные могут быть отслежены и проанализированы наблюдателями, расположенными на серверах N. См. картинку "Механизм с применением центрального компьютера".

На центральном компьютере С, и каждом из серверов N настроены часы, синхронизированные с временем UTC (UTC time). (Современные технологии, обеспечивающие средства для синхронизации часов в течение малой доли микросекунды).
Пусть di обозначают задержки передачи между C и сервером Xi. Пусть di,j обозначим задержки между Xi и Xj. Эти задержки предполагаются постоянными и не меняются от сообщения к сообщению. Мы предполагаем, что задержки в сети удовлетворяет свойствам метрики (metric), в частности: di,j = dj,i (симметрия) and di,j ≤ di + dj (аксиома треугольника).
Для того, чтобы осуществить видоизменение нашего "черного ящика" (с центрального компьютера к эквивалентной группе компьютеров, размещенных в дата-центрах бирж), мы должны сделать некоторые дополнительные предположения:
1. После настройки, алгоритм А реагирует только на текущее время и сообщения, полученные от серверов Xj. (Конечно, алгоритм А может использовать также память о прошлых событиях в принятии своих решений.).
2. Каждый из N серверов отправляет зафиксированные во времени потоки данных с определенной степенью детализации времени. Это означает, что принимающий получает периодические синхронизированные сигналы от каждого сервера, которые характеризуют и "закрывают" каждый интервал времени - будь то миллисекунды или микросекунды. Алгоритм управляет этими сигналами. (Например, сообщение, полученное в момент времени t по алгоритму А, может быть использовано данным алгоритмом только после того, как все синхронизированные во времени сигналы с временными метками, полученными от всех серверов Xi по шкале времени больше или равны t – di . Данная ситуация не является препятствием в случае, если она будет учтена в сценарии центрального компьютера. Это главное требование для достижения эквивалентности наших "черных ящиков", несмотря на любое время или неустойчивость задержки.
3. Выходное значение алгоритма А состоит из сообщений, отправленных серверам. Все сообщения с временными метками, по местному времени алгоритма А. Данное сообщение может содержать любую информацию, в том числе внутренние отчеты о состоянии, относящиеся к текущим или к прошлым событиям.

Механизм совмещенных групп
Здесь мы представляем механизм, который будет дублировать поведение механизма центрального компьютера с использованием N компьютеров C1, ..., CN совместного размещения (colocation) с соответствующими серверами бирж X1, ..., XN. Как и в предыдущем случае, мы считаем, что этот механизм как "черный ящик", где входные и выходные данные могут фиксироваться и синхронизироваться наблюдателями, расположенными на N серверах. См. рисунок "Механизм совмещенных групп".

Для простоты, задержка передачи данных между компьютером Ci и размещенным Server Xi принимается равной нулю. Задержка передачи данных между Ci и Xj берется di,j - такой же, как задержка между Xi и Xj.
На каждой компьютере Ci работает алгоритм Ai, который является модифицированной копией алгоритма A, работающем на центральном компьютере C, описанным в предыдущем разделе. Отличия модифицированной версии:
1. Время, используемое алгоритмом Ai, устанавливается с запозданием на величину di, то есть, он показывает время UTC – di вместо UTC. Например, когда алгоритм A решает прекратить торговлю на время UTC t, Ai то он прекратит торговлю в момент UTC t + di. (Данное изменение удобнее воспринимать, как модификацию алгоритма Ai, нежели как изменение хода часов на Ci).
2. Каждый алгоритм Ajj принимает сообщения со всех N серверов. В частности, сообщения от сервера Xi, которые будут направлены в исходный центральный алгоритм A реплицируются и рассылаются по всем алгоритмам Аj.Репликация сообщений может быть выполнена в аппаратных средствах или в программном обеспечение компьютера Ci, находящемся в связке с Xi.
3. Искусственная задержка di + dj – di,j вводится для всех сообщений, поступивших на Aj от сервера Xi. Задержки сообщений могут быть реализованы либо в аппаратных средствах, либо в программном обеспечении, работающем на Cj. (Данный генератор задержки удобнее воспринимать, как модификацию алгоритма Aj.). Обратите внимание, что, когда i = j, то задержка равна i + di – di,i = 2⋅di. То есть, задержка для всех сообщений, отправляемых сервером Xi в расположенный по соседству компьютер равна Ci это 2⋅di.
4. Алгоритм Ai посылает свое сообщение с выходными данными только в Xi сервер, находящийся в colocation связке. Когда оригинальный алгоритм будет отправлять сообщение на другой сервер Xj, Ai бездействует \ - вместо этого, алгоритм Aj , находящийся в связке с Xj, посылает идентичное сообщение именно в нужное время. Aj может зафиксировать это событие в логе, тем не менее, будет действовать так, как было описано ранее.

Механизмы "центрального компьютера" и "совмещенных групп" эквивалентны
Чтобы убедиться, что механизм "совмещенных групп" работает так же, как механизм "центрального компьютера", нужно удостовериться, что отосланные входные данные приводят к тем же выходным данным, полученным серверами в одно и то же самое время, обоими механизмами "черных ящиков".
Очевидно, что для любого j, алгоритм Aj принимает одно и то же сообщение с входными данными, которое будет получено алгоритмом A, но Aj принимает их после задержки dj по отношению к времени, использующимся в алгоритме А. Именно во время t, алгоритм А получит сообщение от сервера Xi, которое было отправлено в момент времени t – di. Это же сообщение посылается от Xi к Aj с применением генератора искусственной задержки (di + dj – di,j), а затем через линию передачи, которая имеет задержку di,j. Таким образом, поступление данных на Aj происходит в момент времени (t – di) + (di + dj – di,j) + di,j = t + dj.
Задержка di устраняется путем установки времени Aj назад на величину dj. Это означает, что при времени UTC t + dj, все выходные данные Aj (в том числе и время) идентичны выходным данным из A в UTC времени t. Таким образом, Aj делает одни и те же решения в момент t + dj, как и A в момент времени t. Хотя решения, принятые алгоритмом Aj сделаны с задержкой dj, ее выходные данные доставляются мгновенно на сервер Xj (без задержки dj, которые были потеряны при отправке выходных данных с алгоритма A на Xj), что означает, что обе временные метки, поставленные алгоритмом Aj и время доставки сообщений, отслеживаемые Xj, идентичны тем, которые получены алгоритмом А. Это доказывает теорему 1.

Пример:
Чтобы получить некоторое представление о том, как хитро работает механизм совмещенных групп, мы будем использовать пример из статьи журнала Nature. Мы начинаем с одного компьютера - "срединной точки" C, расположенном в геодезическом центре между серверами двух финансовых центров X1 и X2 (Нью-Йорка и Лондона) и представим торговлю EUR / USD на спот рынке Forex). См. рисунок "Механизм с применением центрального компьютера".
Используя простые обозначения, d = d1,2 (около 20 миллисекунд со скоростью света) и h = d1 = d2 = d/2, и, вооружившись базовым методом, изложенным выше, мы сформируем простой функционально эквивалентный механизм, состоящий из пары компьютеров, размещенных в дата-центрах двух бирж, показанных на рисунке "Механизм пары компьютеров, находящихся в Colocation связке с разными биржами".

Далее мы покажем конкретный алгоритм арбитражной стратегии в действии, прослеживая его шаг за шагом в обоих сценариях. Наш алгоритм арбитражной стратегии "серединной точки" выглядит следующим образом: если цена Ask, с одной стороны (например, X1) точно меньше, чем цена Bid на другой стороне (X2), тогда отправляем лимитную заявку на покупку типа FOK (fill-or-kill) на сторону X1 и аналогичную лимитную заявку на продажу на сторону X2. Если оба ордера успешно заполнены, мы добились своего и сделали прибыль. В противном случае (если, скажем, продать на X2 не удалось) - мы отступаем, ликвидируя свою позицию, используя рыночную заявку. Она отправляется на биржу, которая предлагает лучшую цену Bid. (Это не самый умный алгоритм арбитража, однако, этого достаточно, чтобы проиллюстрировать то, что происходит внутри двух "черных ящиков").

В следующей части мы разберем, какой же из вышеописанных вариантов представляет оптимальное решение для HFT арбитражных стратегий. Почему Colocation "преодолевает скорость света" и что по мнению профессиональных арбитражеров - "поистине распределенная архитектура биржи".

Перейти к части 3

Ссылка на первоисточник данной статьи
Перевод: Николай Флёров

Colocation преодолевает скорость света. 1 часть

2015-06-28T21:48:32Z

В данной статье мы рассмотрим вопрос, получают ли трейдеры преимущество, базируя свой компьютер между двумя финансовыми биржами. Например, на корабле в середине океана - вопреки рекомендации из статьи "Physics in finance: Trading at the speed of light" (Mark Buchanan, Nature, 11 февраля 2015 г.). Или же лучший результат покажет торговая стратегия, использующая два взаимодействующих компьютера, размещенных в дата-центрах разных бирж. В доходчивой форме будет рассмотрен вопрос о том, является ли преимуществом распределение торговых стратегий. Либо же наоборот лучше использовать распределенную архитектуру биржевых серверов, которые устраняют необходимость в распределенных арбитражных стратегиях.
Изучив данную статью целиком, вы откроете для себя, какой метод расположения серверов является наиболее эффективным, при работе с HFT арбитражными стратегиями, работая одновременно на нескольких биржах.

Статья из журнала Nature (авторское замечание)

Цитата:

В будущем, когда надводные лазерные сети охватят океаны, изменения в трейдинге могут стать еще более необычными. Место, в котором трейдеры могут получать наиболее актуальную информацию от двух бирж одновременно, находится в их средней точке - между Чикаго и Лондоном, то есть в середине Атлантического океана. В данном месте, трейдеры могут использовать технику, называемую "релятивистский арбитраж", чтобы получить прибыль от сиюминутного дисбаланса цен между Чикаго и Лондоном.
Объяснение: специальная теория относительности говорит, что ничто не может двигаться быстрее скорости света С. Таким образом трейдер, находясь на расстоянии D от биржи может узнать, что там произошло, в лучшем случае, не раньше чем - T = D/C после того, как событие произошло. Между крупными торговыми центрами по всему миру, такие задержки могут быть от нескольких до десятков миллисекунд. Если трейдер стоит на полпути между двумя биржами, он будут получать информацию с обеих сторон после, Т = D/C. В любом другом месте, если расстояние, по крайней мере, одной из бирж будет более удалено, то информации потребуется больше времени, т.е увеличится задержка.

Другими словами, в течение нескольких лет может стать прибыльным устанавливать корабль или платформы для трейдинга на участках ровно между парами финансовых центров по всему миру (см. Fast-trading hotspots).

Статья из Nature предоставляет карту мира с указанием всех мировых финансовых центров и более тысячи точек, лежащих ровно посередине, где высокочастотные трейдеры должны будут устанавливать свои компьютеры, чтобы оптимально использовать данные возможности для арбитража. Как и ожидалось, многие из этих "оптимальных" мест, в действительности "места глухие" (одна точка находится в пустыне, где исчез рейс MH 370). Карты не указывают на важность центров или значение "перспективных точек для трейдинга", но ясно, что наиболее значимые точки лежат где-то в северной части Атлантического океана.

Карта наиболее удобных точек для арбитражного трейдинга

Карта наиболее удобных точек для арбитражного трейдинга [1]. Используется с разрешения издательской группы Nature.

Карта впервые была представлена в издании Relativistic statistical arbitrage[2]
В той статье "серединные точки" взвешивали по скорости оборачиваемости (отношение стоимости акций, обращающихся на бирже в общей рыночной капитализации) – там использовались не истинные геодезические средние точки, как это подразумевается в статье издательской группы Nature. Кроме того, "финансовые центры", определенные в статье как 52 биржи, перечисленные в Всемирной федерации бирж из Годового отчета за 2009г. (World Federation of Exchanges 2009 Annual Report[3] ) - и не включают Forex площадки, которые превосходят все другие торговые центры по показателю величины объема торгов.
Новости относительно оптимального размещения компьютеров для HFT (высокочастотной торговли) была широко освещена профессиональными средствами массовой информации; см. статьи в PhysicsCentral[4], MarketWatch[5], International Business Times[6], и WatersTechnology[7]. Некоторые эксперты приняли данный "факт", как само собой разумеющееся, некоторые же выразили сомнения. Билла Хэртс(Bill Harts), генеральный директор Modern Markets Initiative, группы, которая занимается высокочастотной торговлей, отвергнул данную идею, высказав мысль в электронном издании MarketWatch: "Даже если трейдер может получать данные с обеих бирж быстрее в средней точке, то воспользовавшись преимуществом, имея только один компьютер в средней точке, они будут посылать заявки на рынок с достаточно большого расстояния – и будут всегда медленнее, чем трейдеры, размещенные на локальных рынках".

Головоломка серединных точек.
В статье Nature тривиально утверждается, что середина между двумя биржами является точкой, где наиболее быстрым образом может быть обнаружена возможность арбитража. Что менее очевидно - учитывая, что Марк Бьюкенен, уважаемый физик и автор ошибся - это то, что серединное расположение особенно неблагоприятное место, для принятия торговых решений.
Здесь "шестое чувство” Билла Хэртса является правильным. В своей статье follow-up IBT article[8], он подчеркивает: "Если бы это было возможно, поставить дата центр в Янгстаун, штат Огайо, (примерно на полпути между биржами Нью-Йорка и Чикаго), если бы это место было бы самым благоприятным для HFT, все высокочастотные трейдеры базировались бы там. Но знаете что? Там нет HFT трейдеров в Янгстауне, штат Огайо".
Таким образом, HFT арбитражеры знают, что торговля с средней точке расположенной между биржами - это плохая идея. Тем не менее, заявление Хэртса не совсем корректно – трейдер, торгующий с серединной точки на самом деле, достаточно быстр, чтобы воспользоваться нарушением паритета цен между двумя биржами. Недостатком же, по сравнению с "системой компьютеров, размещенных на реальных рынках", является то, что – компьютер в серединной точке после подачи заявки как бы "слеп" и не может контролировать заявку достаточно хорошо. Читайте дальше, чтобы осознать действительно невероятное преимущество размещения серверов в дата-центрах бирж и распределенных торговых стратегий.

Решение задачи.
Для универсальности далее по тексту термином "серверы", будет заменен термин "биржевые-серверы", потому что наш результат относится к сценариям носящим более общий характер, чем просто алгоритм связи с финансовыми биржами. Мы будем использовать термин "компьютер", когда говорим о не серверных компьютерах под управлением программного обеспечения, которое взаимодействует с серверами (например, алгоритмическая торговая стратегия).
В следующих нескольких разделах мы докажем одну фундаментальную теорему. (Пожалуйста, не беспокойтесь - доказательство будет так же просто, как строительство из Lego блоков.)

Теорема 1. Любой алгоритм, который работает на одном центральном компьютере, расположенном в любой точке мира и соединен с одним, или большим количеством серверов (N≥ 1), может быть воспроизведен с использованием нескольких компьютеров, работающих в связке с серверами, таким образом, что такая реализация (зарегистрировано серверами) функционально ничем не будет отличается от оригинального одно-компьютерного решения.
Доказательство довольно просто. Во-первых, мы формально определяем единый центральный механизм компьютера. Затем мы покажем, как построить эквивалентный механизм, который использует группу компьютеров, размещенных в дата-центрах бирж, без необходимости центрального компьютера. Другими словами, мы начинаем с черного ящика реализованного с помощью центрального компьютера и покажем, как можно построить эквивалентный черный ящик без центрального компьютера.

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

*Colocation (MICEX)

Перейти к части 2

Ссылка на первоисточник данной статьи
Перевод: Николай Флёров

Создание торгового робота на Plaza2

2013-03-13T10:36:09Z

Введение.

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

Роутер.

При использовании торгового терминала Quik подключение производится непосредственно к терминалу на локальной машине. Когда используется Plaza2, то подключение происходит к клиентскому роутеру, который может находить как на локальной машине, так и на удаленной. Роутер позволяется подключаться к нему из нескольких приложений одновременно, что является большим преимуществом. Например, можно упростить инфраструктуру торгового робота и запускать каждую стратегию в виде отдельного приложения, это так же позволит повысить устойчивость каждого отдельного робота.

Из недостатков можно выделить отсутствие, какого бы то ни было, пользовательского интерфейса, т.е. невозможность ручного управления позициями при работе робота. Для этих целей можно использовать простой «самописный терминал», с помощью которого можно будет просматривать стаканы, списки заявок и сделок, портфели и лимиты, а так же выставлять заявки в случае необходимости. В качестве каркаса подобного терминала может служить S# пример Plaza\SampleGUI.

Роутер представляет собой самостоятельное приложение, единственной функцией которого является передача данных от биржи клиенту и наоборот. Есть два варианта запуска локального роутера: в виде службы и консольного приложения. Способ запуска роутера выбирается при его установке. При использовании консольного приложения, пользователь может сделать несколько конфигурационных файлов и запускать роутеры для разных логинов или серверов с помощью простых командных файлов. Полное детальное описание процесса установки и настройки роутера вы можете найти в файлах документации здесь и здесь.

Подключение к роутеру.

В настоящее время роутером поддерживаются два вида соединений:

Соединение посредством протокола TCP/IP. Медленнее, удобно для отладки, может связываться с роутером, установленным на другой машине
Соединение посредством разделяемой памяти (lrpcq). Быстрее, оптимально для боевых систем, работает исключительно в рамках одной машины.

Платформа S# поддерживает оба типа соединение и по умолчанию используется TCP/IP соединение. Для использования lrpcq подключения необходимо до подключения к роутеру выставить флаг:

Код

Trader.UseLocalProtocol = true;

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

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

Цитата:

[AS:Local]
префикс_0=пароль
префикс_1=пароль
префикс_2=пароль

Т.к. одно приложение может одновременно использовать несколько подключений к роутеру, то к имени, указанному в AppName добавляется его номер, таким образом, соединения именуются как {префикс_номер}, поэтому в конфигурации роутера необходимо указать все названия имен с учетом их номеров.
После настройки роутера, необходимо дополнительно указать пароль для S# коннектора, который был сохранен в файле конфигурации роутера. Для указания сетевого пароля используется поле Password, которое может использоваться в двух вариациях:

в случае если было задано поле Login, то поле Password используется для указания пароля для подключения серверам биржи или брокера;
если поле Login задано не было, тогда Password будет использоваться как пароль для локального соединения.

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

Схемы данных.

В платформе Plaza2 все данные транслируются сервером на клиентов в push-режиме, клиент постоянно получает последовательность изменений данных в соответствующих таблицах. Все данные, получаемые роутером, группируются в таблицы, которые в свою очередь сгруппированы в потоки.

Для определения набора полей, которые будут транслироваться в каждой таблице, используются схемы данных. Протокол Plaza2 позволяет использовать два варианта схем данных:

Серверная схема данных
При открытии потока пользователю не требуется задавать какое-либо описание получаемых данных, в момент подключения роутер получит схему данных с сервера, и все данные будут приходить согласно полученной схеме. Таким образом, перед пользователем не стоит задача поддержания схемы в валидном состоянии, т.к. набор доступных полей для каждой таблицы может меняться с течением времени.
Пользовательская схема данных
В случае, когда стандартный набор полей в таблицах содержит лишние или не содержит необходимых полей, пользователь может задать свои схемы данных для каждого потока и таблицы отдельно. Пользовательские схемы описываются с помощью ini-файлов, в которых указывается название схемы данных, названия таблиц и список полей для каждой таблицы. Далее, при открытии потока данных, передается путь к соответствующему файлу с настройками схемы и ее название, и роутер отправляет схему на сервер для согласования. В случае если схема была принята на серверной стороне, все данные будут приходить с указанным набором полей. Если в схеме есть недопустимые поля или типы полей, то с сервера придет соответствующее сообщение, поток данных при этом открыт не будет, более детальное описание ошибки будет записано в клиентский лог-файл, который располагается в папке \StockSharp_Plaza\Logs\.
Полное описание формата данных для всех транслируемых таблиц можно найти в файле документации 2, а так же в описании схем данных, которое устанавливается вместе с роутером.

Для того чтобы исключить необходимость постоянного обращения к документации Plaza2, возможные опечатки при задании схем данных, не оперировать непонятными сокращениями в названиях полей и их типами, в S# было введено понятие метаданных, которые содержат описания всех доступных таблиц и полей, которые могут быть в этих таблицах. Описание метаданных находится в пространстве имен StockSharp.Plaza.Metadata. Например, все доступные таблицы представлены полями класса PlazaTableRegistry, а все доступные поля для таблицы сделок по фьючерсам - ColumnRegistry.TradeFuture.
Набор таблиц, данные из которых необходимо будет получать при подключении к серверу, задается с помощью свойства PlazaTrader.Tables, куда необходимо добавить нужные таблицы и удалить ненужные. Для ручного добавления и удаления таблиц можно необходимо вызвать соответствующую функцию у PlazaTrader.Tables и передать в качестве параметра одно из полей PlazaTrader.TableRegistry, например, для добавления полного ордерлога необходимо выполнить:

Код

PlazaTrader.Tables.Add(PlazaTrader.TableRegistry. AnonymousOrdersLog);

В определенных ситуациях, выбор необходимого набора таблиц для получения данных можно оставить конечному пользователю, для этого в S# присутствует специальный графический компонент PlazaTableListComboBox, который представляет собой выпадающий список с набором всех доступных таблиц (рис. 1). Каждая строка представлена в виде трех столбцов: описания таблицы, названия потока репликации, в котором транслируется таблица и названия самой таблицы, последние два столбца соответствуют названиям потока и таблицы в документации по Plaza2.

Для того чтобы передать список выбранных таблиц в PlazaTrader, в библиотеке S# присутствует специальный метод расширения SyncTables, который можно использовать следующим образом:

Код

PlazaTrader.SyncTables(Tables.SelectedTables);

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

Поля таблицы, для которых нет соответствующих полей у объектов S#, будут записываться в специальный словарь ExtensionInfo объекта S#. Например, если нам необходимо получать данные по сбору по сделке продавца, то в таблицу TradeFuture необходимо добавить столбец SellFee:

Код

PlazaTrader.TableRegistry.TradeFuture.Columns.Add(PlazaTrader.TableRegistry.ColumnRegistry.TradeFuture.SellFee);

далее, в момент обработки данных по сделке, данное поле можно будет получить следующим образом:

Код

var fee = trade.ExtensionInfo[PlazaTrader.TableRegistry.ColumnRegistry.TradeFuture.SellFee];

Подробное описание работы с дополнительными полями и произвольными таблицами можно найти в документации по S# в разделе Российские коннекторы - Plaza2.

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

При подключении к роутеру, все выбранные таблицы группируются по потокам, которые, в свою очередь, группируются по разным соединениям. Каждое подключение к роутеру может использоваться для передачи данных по одному и более потоку репликации. Разделение потоков по разным соединениям необходимо для уменьшения влияния процесса обработки одних данных на другие, например, разделение потоков с таблицами сделок и агрегированных заявок по разным подключениям, позволяется обрабатывать стаканы, не дожидаясь пока будут обработаны все пришедшие сделки. В библиотеке S#, все получаемые потоки изначально сгруппированы таким образом, что наиболее нагруженные потоки репликации обрабатываются в различных подключениях. Если, по каким-либо причинам, стандартная группировка потоков не подходит для решения поставленных задач, ее можно изменить с помощью ConnectionGroupping. Например, если необходимо получать все потоки репликации в одном подключении, то необходимо для каждого потока указать одинаковый индекс подключения:

Код

var streamRegistry = PlazaTrader.TableRegistry.StreamRegistry;
var groupping = PlazaTrader.StreamManager.ConnectionGroupping;

groupping[streamRegistry.Aggregation5Future] = 0;
groupping[streamRegistry.Aggregation5Option] = 0;
groupping[streamRegistry.Aggregation20Future] = 0;
groupping[streamRegistry.Aggregation20Option] = 0;
groupping[streamRegistry.Aggregation50Future] = 0;
groupping[streamRegistry.Aggregation50Option] = 0;
...
groupping[streamRegistry.TradeFuture] = 0;
groupping[streamRegistry.TradeOption] = 0;

Посмотреть сколько открывается соединений, и с какими названиями, можно в логе PlazaTrader-а в момент подключения:

Цитата:

PlazaTrader | 30.01.2013 15:10:21.761 | | Attempted to connect Webinar_0.
PlazaTrader | 30.01.2013 15:10:21.819 | | Attempted to connect Webinar_1.
PlazaTrader | 30.01.2013 15:10:21.820 | | Attempted to connect Webinar_2.

Управление ревизиями.

Каждая реплицируемая таблица имеет в своей структуре несколько служебных полей, предназначенных для обеспечения механизма репликации. Одним из полей является уникальный номер изменения в таблице. При любом изменении в таблице (вставке, редактировании, удалении записи) затронутая запись получает значение replRev, равное максимальному replRev в таблице до изменения +1. После согласования схем данных, клиент отсылает на сервер максимальные значения номера ревизии для каждой таблицы. Начальная синхронизация заключается в том, что сервер присылает клиенту все данные с номерами, большими, чем те, что указал клиент. Если клиент не указал номер ревизии для таблицы, то данные по этой таблице будут приходить в полном объеме.

Для того чтобы получение данных начиналось с последних сохраненных ревизий, необходимо добавить нужные таблицы в PlazaRevisionManager.Tables:

Код

var revisionManager = PlazaTrader.StreamManager.RevisionManager;

revisionManager.Tables.Add(Trader.TableRegistry.TradeFuture);
revisionManager.Tables.Add(Trader.TableRegistry.TradeOption);

При первом подключении, после добавления таблиц в RevisionManager, данные так же будут получены в полном объеме, т.к. информация о сохраненных номерах ревизий еще отсутствует. После переподключения, данные будут скачиваться с номера последней сохраненной ревизии.
Интервал, через который сохраняется номер последней ревизии, доступен через PlazaRevisionManager.Interval. По умолчанию файл с номером последней ревизии по выбранной таблице сохраняется в папку \StockSharp_Plaza\Revisions. Для того чтобы перезакачать все данные, достаточно удалить файлы из папки Revisions.

Полный ордерлог.

Полный журнал заявок – сервис Московской биржи, который позволяет получать список всех торговых транзакций, принятых торговой системой в текущую торговую сессию с указанием текущего статуса заявок (поставлена/удалена) и изменений параметров транзакции (частичных исполнений, передвижений заявки). Также в журнале отображается запись о сделке, с указанием номера сведенной в данную сделку заявки. Ордерлог - самый глубокий и детальный уровень биржевых данных, который доступен трейдеру. По данным ордерлога можно построить стаканы, получить тики и многое другое.

Для получения и обработки всех данных по ордерлогу необходимо добавить таблицу AnonymousOrdersLog:

Код

PlazaTrader.Tables.Add(PlazaTrader.TableRegistry. AnonymousOrdersLog);

и подписаться на обработку события NewOrderLogItems.
Ордерлог, в отличие от потока агрегированных заявок, содержит информацию по всем заявкам, таким образом, по ордерлогу может быть построен стакан полной глубины. Библиотека S# предоставляет функционал, позволяющий автоматически строить стаканы и тики по данным ордерлога.

Для построения стаканов по журналу заявок необходимо выставить соответствующий флаг
Код
```
PlazaTrader.CreateDepthFromOrdersLog = true;
```
при установке этого флага автоматически отключается обработка потоков агрегированных заявок и для получения данных добавляется таблица AnonymousOrdersLog.
Для построения тиков по журналу заявок необходимо выставить флаг
Код
```
PlazaTrader.CreateTradesFromOrdersLog = true;
```
при установке этого флага отключается обработка потоков журнала сделок по фьючерсам и опционам и для получения данных добавляется таблица AnonymousOrdersLog.

Сохранение и восстановление настроек.

S# Plaza2 коннектор предоставляет широкие возможности для управления настройками подключения, списком выбранных таблиц, группировкой потоков по соединениям и другими настройками. В одних случаях, эти настройки могут быть зашиты в торговом роботе, в других, может возникнуть необходимость предоставить возможность редактировать эти настройки конечному пользователю. Для удобства, все коннекторы S# содержат встроенные механизмы сохранения и загрузки настроек с помощью методов Save и Load.

Для сохранения и загрузки настроек из внешнего файла можно воспользоваться соответственно сериализацией и десериализацией, реализованной в S#:

Загрузка

Код

var trader = new PlazaTrader();
if (File.Exists("trader.xml"))
{
//Загрузка настроек из существующего конфигурационного файла
var settingsStorage = new XmlSerializer<SettingsStorage>().Deserialize("trader.xml");
trader.Load(settingsStorage);
}

Сохранение

Код

//Сохраняем настройки в файл
var settings = new SettingsStorage();
trader.Save(settings);
new XmlSerializer< SettingsStorage >().Serialize(settings, " trader.xml");

S#. Автоматическая торговля (вебинар про все нюансы и настройки Quik)

2013-09-10T23:16:08Z

Расскажем про все нюансы и настройки Quik для работы с платформой StockSharp!

Кратко пробежимся по S#.Studio, S#.Data и S#.Api!

Записаться на вебинар можно здесь

S#. Автоматическая торговля (вебинар про анализ маркет-данных)

2013-09-10T23:26:22Z

Все про данные в платформе S#!

Сегодня вебинар в 19:00, записаться можно здесь.

Краткий план:

Различные источники данных (особенности)
Сохраняем и просматриваем данные
Анализируем, совмещаем инструменты

S#. Автоматическая торговля (вебинар, базовое про C#, спредовый робот)

2013-09-10T23:27:18Z

Достаточно интересные темы раскрываются:

Программирование на .Net (C#) в целом. Базовые понятие, которые могут помочь написать первое приложение на S#.
Создание спредового робота, создание интересных конструкций.

Валютный арбитраж на рынке FORTS

2012-06-07T21:18:40Z

Мечтой каждого трейдера является risk-free стратегия.

В этой статье поговорим о валютном арбитраже на срочном рынке ММВБ-РТС. Так как у нас нет возможности построить простую стратегию, мы создадим стратегию сложного арбитража с тремя инструментами. Данная тема много раз перетиралась на различных порталах, но я задался вопросом - имеет ли она еще место быть?

Для ответа на вопрос я создал приложение (через API), экспортирующее данные по стаканам из терминала Альфа-Директ в рабочую книгу Excel.

Используемые инструменты:

Eu-6.12
USD-6.12
EURUSD

В правой колонке - рассчитанное значение фьючерса на доллар-рубль, а в левой - реальное значение.
В качестве параметров для расчета я принял среднее значение внутри спреда.

Теперь нам остается только построить график этого спреда(всего лишь за период в 15 минут). Как видим, в течение 15 минут наш спред 4 раза переместился с точки 0 до 10(в рублях).

Наиболее благоприятное время для торговли данной стратегии - с 17:00 до 18:45 по Москве в период повышенной волатильности, когда спред в каждом стакане наиболее узкий, а спред между парами достигает 80 рублей.

Общее ГО по трем инструментам составит чуть более 4200, то есть стратегия имеет право занять место в вашем портфеле!

FIX протокол. Вебинар от StockSharp

2016-06-09T15:10:47Z

Друзья! Сегодня мы публикуем наш вебинар по FIX/FAST протоколу и одноименному коннектору от StockSharp.
Смотрим! Учимся! Пишем роботов! PROFIT!!!

Материалы для скачивания

Кстати не забываем, что до 11 июня действуют скидки КиберПонедельника, в том числе и на FIX/FAST! Успей сейчас!

Коннекторы StockSharp. Запись вебинара.

2016-05-18T10:31:35Z

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

В вебинаре рассказывается про наши коннекторы и базовые основы работы с ними.

Материалы для скачивания.

Старая песня о главном: валюта (часть 2)

2016-02-02T11:32:41Z

В предыдущей статье мы остановились на том, что единственный реальный долг государства – это долг в валюте, именно его необходимо отдавать, не прибегая к помощи печатного станка. Давайте посмотрим, как у нас происходит оборот валюты. Допустим, мы не берем в долг у наших заклятых друзей, а просто продаем им наше все. Естественно за деньги, естественно за доллары или евро, или юани не суть. В этом случае в страну устремляется поток иностранной валюты в форме выручки за проданные товары, т.е. эту валюту не нужно никому отдавать – она представляет собой чистые ПРАВА требования к государству ее эмитировавшему продать нам товары, производимые в этом государстве.

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

Сие означает, что в условиях конкуренции в китайцами местное производство проиграет неравный бой, а следовательно завтра перекупщик притаранит оттуда товаров побольше, чем вчера (раз эти раскупили, то и новый объем схавают), а это в свою очередь значит, что ему понадобится побольше валюты. Действительно допустим курс 30 руб. за 1 долл., наш бизнесмен втарил 10 000 баксов и накупил на них товаров, продал с +2 процента получив за товары 900 тыс. руб., увидел, что вау как клево бизнес пошел и побежал на биржу втаривать баксы на фсе, уже по 31 руб., но выросший курс его не пугает, ведь все равно получается 29 тыс. баксов, на которые он побежит покупать китайские товары, чтобы снова наварить 2 процента и так далее.
Все это в конечном итоге приведет к дичайшему спросу на валюту, которой будет не хватать.

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

В условиях России 2000-х множество фабрик и заводов уже было закрыто после лихих 90-х, оставшиеся либо встроились в рынок, либо оказались в поддержке государства. Кроме того, нужно понимать, что описанная выше схема не приводила к мгновенному росту импорта, поскольку коммерсы наваривали таки не 2%, а поменьше, где-то 50-70, народ не обладал достаточной покупательской способностью, чтоб сметать следующую партию под ноль и поэтому приходилось довольствоваться теми объемами, которые раскупались. Кроме того, рост всех сырьевых товаров на мировых рынках приводил к возрождению заводов и фабрик ориентированных на экспорт нефти, газа, алюминия, никеля и т.д.

Также, бум начался в сфере, которую импортировать невозможно – в строительстве. Долларовый поток при валютном коридоре уходил в квадратные метры в Москве и регионах, взвинчивал цены на жилье и коммерческие площади, нужные под торговлю китайскими подделками. Начала развиваться сфера услуг, единственным двигателем которой является лишнее бабло. Ведь если денег нет, то зачем мне пицца, да еще и с доставкой, я сейчас из холодильника зеленую колбасу достану, там же сыр с плесенью завалялся (не французский), батон покрошу и в духовку. Ну и сосед обещал с бутылочкой прийти, без нее есть реальный риск на лекарства больше потратить.
В общем и целом оно как то так двигалось и драйверы были понятны.

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

Так вот ЕДИНСТВЕННЫМ драйвером в нормальных условиях, который может создать такой дефицит является ДОЛГ. Только по долгам есть четкое обязательство в определенный момент вернуть взятую ранее сумму с процентами, все остальное элементарно регулируется рынком и курсом.

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

Старая песня о главном: долги (часть 1)

2015-07-13T14:58:32Z

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

Много уже копий сломано на предмет государственного долга. В частности актуализировавшиеся экономические проблемы Южной Европы и самый яркий пример Греции, которая должна МВФ порядка 1,6 млрд. евро, подстегивают интерес к этим темам. Сегодня мы постараемся непредвзято разобраться в механизмах возникновения государственного долга, понять, а так ли страшен гигантский по номинальным значениям долг США и не такой гигантский долг греков.

Прежде всего, начнем с истоков и подумаем, а существует ли вообще в природе государственный долг, кто здесь кредитор, а кто заемщик. Не спешите с ответом, прямой ответ в лоб, что кредитор здесь какой-либо фонд или частное лицо, а заемщик государство в корне неверен, по сути. Чтобы это понять, нужно задаться вопросом, а откуда у нашего фонда возникли деньги, которые он может дать в долг, как они образовались? Так мы приходим к механизму эмиссии денег, который на монопольном праве принадлежит государству. Итак, рассмотрим гипотетический пример, Минфину срочно нужны деньги на финансирование государственных обязательств, скажем 1 млрд. руб. Допустим, денег в экономике еще нет, в этом случае, Минфин первым делом идет в ЦБ и просит эмитировать этот самый 1 млрд. руб. под облигации федерального займа.

В первой итерации проходит следующая сделка:

Теперь у Минфина есть 1 млрд. руб., которые он может потратить, эти деньги уходят в экономику и расходятся по предприятиям, домохозяйствам и т.д. в целом они никуда не деваются, если кто то потратил 1 руб., то вторая сторона сделки должна этот самый рубль получить. Допустим на данном этапе 1 млрд. руб. это достаточная сумма для функционирования экономики, но через некоторое время сумма свободно обращающихся в системе денег – уменьшится. Причиной этому послужит фактор неравномерного распределения доходов и как следствие возникновение сбережений. Действительно, когда доходы распределены неравномерно, в системе появятся люди, которые не потратят все полученные деньги, т.е. часть денег будет изъята из оборота. В лучшем случае эти изъятые из оборота деньги пойдут в банки и тогда запустится механизм банковской эмиссии, в худшем – они попадут под подушку и не выйдут оттуда до наступления черного дня, который может и не наступить никогда.
Продолжим наше рассмотрение оценкой первого сценария, а именно банковской эмиссии. Сбережения в полном объеме поступают в банк, значит банк уже имеет деньги, которые он может дать в кредит, предварительно не забыв отдать ЦБ определенную сумму на резерв, т.е. часть сбережений, скажем 20%. Это значит, что получив на вклад 1 млн. руб. банк отдаст 200 тыс. руб. в ЦБ, а остальные 800 тыс. сможет выдать в кредит.

Поскольку доходы распределены неравномерно, то этот кредит обязательно возьмут, потому что иначе возникает проблема с ликвидностью (тут, должно уже быть понятно, что она и так возникнет, но попозже), после цикла выдачи кредитов деньги уходят в экономическую систему по 2-ому кругу, после которого доходы снова перераспределились и зависли на счетах сбережений у определенной группы лиц. Вот тут, уже начинает остро не хватать ликвидности для обеспечения нормального функционирования экономики. Это происходит потому, что существует норма резервирования, через которую ЦБ возвращает обратно эмитированные ранее деньги, хуже того, в том же направлении нехватки денег работает ставка процента.

Решая эту проблему, ЦБ запускает новый виток эмиссии, покупая новые обязательства МинФина. Теперь общий объем эмитированных денег возрастает, одновременно возрастает государственный долг. Поскольку денег в системе становится больше, то возникает инфляция, на которую также оказывает влияние процентные ставки, сложившиеся в экономике. В принципе инфляция не может быть ниже процентных ставок.

Продолжая модель, можно говорить о том, что ЦБ будет продолжать эмитировать ликвидность, Минфин будет продолжать эмитировать обязательства и они будут только расти, не забывая о том, что Минфин должен не только тело долга, но и проценты, темп роста размеров долга будет со временем экспоненциальным. Вот только есть ли тут, что-то страшное? Ведь что происходит, Минфин взял у ЦБ 100 млн. руб. на проценты, отдав взамен ОФЗ на 100 млн. руб., после этого Минфин отдал ЦБ 100 млн. руб. по процентам и остался должен уже на 100 млн.руб. больше тому же самому ЦБ. ЦБ же вернув деньги от Минфина, просто утилизировал их как ненужную денежную массу. После этой операции номинальный объем долга вырос на 100 млн. руб., а денег в системе не прибавилось, то есть размер долга правительства в национальной валюте может быть абсолютно любым, потому что первичным его держателем является ЦБ и долг является всего лишь средством обеспечивающим эмиссию.

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

Логика подсказывает, что единственной целью привлечения кредита в иностранной валюте является финансирование затрат на приобретение товаров, произведенных за рубежом, при этом экономическая теория говорит нам, что привлекать кредит имеет смысл, только в случае наличия положительного эффекта финансового левериджа, а он в свою очередь, возникает, только при покупке ИНВЕСТИЦИОННЫХ товаров (оборудования, технологий и т.п.). При покупке за кредитные деньги потребительских товаров (джинсов, пармезана, телевизоров) экономика государства начинает скатываться в финансовую яму и начинает полностью зависеть от зарубежных кредитов.

(продолжение следует)

Теория и практика дефолтов

2014-12-16T15:38:52Z

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

Модель информационного управления.

Теория игр относится к числу тех немногих наук, момент «оформления» которых в отдельную дисциплину известен достаточно точно. В 1944 г. вышла монография Дж. фон Неймана и О. Моргенштерна «Теория игр и экономическое поведение», в которой были изложены известные на то время результаты. Монография положила начало бурному развитию этой науки, не прекращающемуся и по сей день.

График №1

Хотя и не сразу, но теоретико-игровое моделирование заняло прочное место в арсенале методов экономического анализа. Завершение этого процесса можно отнести, по-видимому, к 90-м годам. В 1994 г. Нобелевскую премию по экономике получили Дж. Нэш, Дж. Харшаньи и Р. Зельтен, внесшие большой вклад в развитие теории игр. С тех пор любое изложение основ современной экономической теории так или иначе сообразуется с теорией игр.

С теоретико-игровой точки зрения задача управления активной системой (элементы которой способны к целенаправленному поведению) состоит в том, чтобы создать для управляемых субъектов (агентов) игру с такими правилами, чтобы ее исход (набор действий агентов) был как можно более благоприятным для управляющего органа (центра). Сам центр не входит в число игроков , а лишь формирует условия их взаимодействия («правила игры») . (Убедительно просим запомнить выделенное предложение). В дальнейшем понятия «игрок» и «агент» мы будем считать синонимами (отметим, что первое характерно для теории игр, второе – для микроэкономики).

Приведенные ссылки говорят об одном: рыночной макроэкономики нет, есть макроигра. Забегая вперед, скажем: доллар, кредит, кредитная ставка, золото, биржа, акции рыночными инструментами не являются. Данные величины сосредоточены в одних руках и устанавливаются произвольно, т.е. они – фишки в чьей-то игре. Официально это признано в 1944 г. Тогда же, кстати, образовался Международный валютный фонд – МВФ. Как увидим позже, не случайно….

Что это за игра?

В принципе, игра одна – "Поле чудес" в разном виде. В основе «Игры» - финансовая пирамида. Принцип действия, полагаем, объяснять не надо – все знают МММ. МММ и другие разновидности финансовых пирамид есть всего лишь алгоритм одной «Большой игры».

Способами управления игрой или «пирамидой» являются:

1). Доллар ($) – как всемирное платежное средство есть первая комплексная (мнимая), манипулируемая величина, не отражающая в каждый момент времени реальное положение дел и являющаяся лишь фишкой в игре. Доллар перестает отражать реальную цену товара, т.к. появилась возможность искусственно манипулировать стоимостью этой фишки (речь идет не о курсах валют). Второе свойство доллара – его самого сделали товаром.

2). Кредитование – собственная емкость, куда должно перетечь содержимое чужих «амбаров» за счет манипуляции реальной стоимости $ (разбалансировка экономической системы). Доллар - это рычаговый инструмент главного игрока: сначала необходимо разбалансировать систему (например, подняв цену на золото), в результате чего понижается относительная стоимость доллара и можно раздать всему миру дешевые(!) кредиты; после чего поднять его (доллара) стоимость и «собрать урожай». Процентная ставка как дополнительное средство сбора «дани» не является основным, а выполняет функцию рычага и ширмы.

Т.о. искусственно поднять стоимость доллара выгодно, если раздать всему миру кредиты в долларах. Тогда люди отдают не только сумму кредита и процент по нему, а значительно больше, т.к. $ - отображающая фишка, которая в разное время отображает разное количество материала. Другими словами, меняя во времени стоимость такого инструмента, как доллар, можно заниматься отъемом реальных материальных ресурсов (РМР) и реальных материальных процессов (РМП) у граждан, предпринимателей, государств.

График №2

т.е. раздавать кредиты народу, предпринимателям и государству выгодно в периоды: Т1-2, Т3-4, Т5-6, а собирать урожаи в периоды: Т2-3, Т4-5, Т6.

Периоды Т1-2, Т3-4, Т5-6 → характеризуются мощными инвестициями во все, что можно. Периоды Т2-3, Т4-5, Т6 → характеризуются оттоком «перепуганных инвесторов», отъемом РМР (захвата должника, т.е. его земель, территорий, всего, что у него есть).

Сам механизм поднимания и опускания стоимости доллара не есть свободный и рыночный, он – инструмент «игры». В которой мировая система, повязанная кредитами, в переводе на реальную стоимость РМР все отдает и еще остается должна. Опустили - подняли относительную стоимость доллара, – вытащили «улов».

3). Следующий способ управления игрой (управления игровой площадкой) – биржа, которая, в конечном итоге, контролируется теми же лицами, которые манипулируют долларом.

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

А что до прочих акционеров (скажем, в Америке их основу составляют пенсионеры и пенсионные фонды), то им остается лишь тешить себя хорошо развитым чувством хозяина и надеяться на «светлое завтра», которое, как известно, наступает не для всех…. В эпохи кризисов и потрясений пожилые люди часто лишаются своих сбережений…».

Акции – еще одна, вторая комплексная величина (плоскость, измерение). Это также мнимая, не существующая реально, а отражающая (отображающая) какие-то реальные материальные процессы в какой-то комплексной области – виртуальной, не существующей в мире реальных материальных ресурсов (РМР) и реальных материальных процессов (РМП). Это фишка, также как и доллар – комплексная фишка, только другого измерения. В отличие от доллара она манипулирует не только стоимостными параметрами каких-то материальных процессов, но и таким параметром, как право собственности, т.е. кому принадлежат сейчас, и кому будут принадлежать потом какие-либо РМР и РМП. Т.е. эта комплексная величина позволяет в какие-либо РМП, уже описываемые мнимой (комплексной) величиной доллара вкачивать средства (доллары и мнимые, и реальные), создавая некий многоукрупненный процесс во второй комплексной величине (на плоскости). А именно – на бирже, где происходит другая, более крупная игра в общей «пирамиде», в которой доллары уже являются самостоятельным инструментом. Где Великим и Могучим ставят грандиозные подножки. Сам этот некий укрупненный процесс и есть ни что иное, как финансовые пирамиды или «амбар» с урожаем вкладчиков.

Акции на акции. Это третье комплексное измерение, описывается тройными интегралами функций комплексных переменных. Это новое измерение игры. Печатается много долларов, необеспеченных ничем или обозначается создание новых долларов в электронном виде. Собственно, это ни для кого не секрет, но! Чтобы в примитивной схеме "товар – доллар – товар" доллар не потерял видимой ценности, а на подозрительном рынке акций шел живой процесс, владельцы игры придумали новые измерения, в которых они автоматически на порядок состоятельнее. Т.е. деньги в реальной экономике могут проходить холостым ходом, но чтобы поддерживать свою пирамиду (механизм) в живом виде, чтобы за доллары можно было все скупать, они наращивают комплексные пространства игры. Т.е. наращивают количество самих пространств, и уводят основную игру в новое измерение для перемещения туда свободных финансовых средств (электронно-бумажных фикций). О том, что это за пространства, мы поговорим ниже.

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

Фиктивные доллары с реальной покупательной способностью, виртуальные среды с астрономическими суммами, увод игры в запредельные квазипространства – все это уже из высшей математики. Эта точная наука полностью описывает теорию игр…. Здесь же важно увидеть одно: выиграть в этих и других подобных "лохотронах" все равно, что выиграть в электронную игру, которая при каждом вашем удачном шаге будет до бесконечности увеличивать скорость и сложность ходов, пока вы не проиграете, а вы при этом платите каждую минуту все, что зарабатываете. Т.е. если бы можно было в общем и целом обыграть игральные автоматы, их бы никто не выпускал. Обыграть игровой автомат, в алгоритме которого заложено, чтобы вы приносили деньги и проигрывали, можно только кувалдой.

Немного о равновесии систем

Ресурсы в любом своем виде представляют энергию или сумму всех потенциалов и являются как бы «единым полем».

1. Равновесная система характеризуется единым объемом энергии, который складывается из суммы всех потенциалов и со временем плавно увеличивается за счет увеличения общего ВВП.

2. Любая замкнутая система стремится к равновесию.

3. Чтобы ограбить всех, нужно – вывести систему из равновесия, т.е. ее нужно деформировать.

К примеру, поднять стоимость золота в цене относительно доллара (мы говорим – «относительно», т.к. второе свойство доллара – товар), соответственно потенциал доллара будет ниже прежней равновесной точки. А потенциал золота – выше прежней равновесной точки.

При раздвижении друг относительно друга двух больших частей ($ и золота, к примеру, или можно $ и нефть) в системе создается огромная разность потенциалов, или ЭДС (чтобы электрики не цеплялись за терминологию, назовем ЭДС – энергодвижущей силой).

После деформации любая система стремится к равновесию. В нашем случае это происходит в виде эмиссии $ в общемировое пространство (инвестиции в финансовом секторе, кредитование).

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

Новая деформация системы опять стремится к равновесию и отдает обратно все доллары, только с прилипшими к ним чужими «урожаями» (кроме %). Т.к. фишка $ - одна, а ее относительная стоимость в разное время – разная.

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

Золото обладает двойственностью:

- с одной стороны это потенциал, который может «давить» на все и менять относительный вес других частей поля, таких как доллар и нефть;

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

Имея в одних руках и золото, и доллар, и такой рычаг, как процентная ставка доллара, появляется 100% возможность деформировать систему в любом направлении. И, к примеру, параллельно поднимая золото, доллар и процентную ставку кредита можно «задавить» и нефть, и все остальные ресурсы общего поля (поднять ставку в час Х).

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

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

Поэтому мы и видим на графиках, что значительное опускание золота относительно равновесного состояния системы всегда приводит к опусканию нефти и что это всегда приводит к отъему «урожая».

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

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

График №3

Вверх - вниз «урожай» собран
вверх - сеть забросили, вниз – сеть с уловом вынули.

График №4

Колебания в системе №1 – волновой процесс (пример – график изменения «цены» доллара), в результате которого и происходит перетекание энергии (ресурсов) из одной системы в другую. По закону сохранения, энергия (в т.ч. деньги, собственность) не возникает ниоткуда и не исчезает бесследно.

А теперь о самой игре

.... далее читайте в оригинале.

Высокочастотные трейдеры на рынке интернет-рекламы.

2014-11-19T10:35:29Z

В здании из красного кирпича в Нью-Йорке, одна из стартап-компаний использует собственные компьютерные программы для поиска арбитражных возможностей на рынках, делает миллионы сделок каждый день, генерируя оборот в десятки тысяч долларов. Она не продает и не покупает акции, облигации, товары. Ее специализация – онлайн реклама.

Высокочастотные трейдеры нашли новую нишу и новый рынок. Значительный процент от миллиардов объявлений, появляющихся на компьютерных экранах продается предложившему наилучшую цену на онлайн площадках, таких как AppNexus, Microsoft Ad Exchange (MSFT), PubMatic, Rubicon Project (RUBI), и Yahoo! Ad Exchange.

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

Это множество сделок порождает возможности для арбитражеров. Используя компьютерные программы, трейдеры сканируют рынки в поиске ценовых неэффективностей, покупая и продавая объявления с минимальной прибылью за доли секунды. «Я вижу много парней, которые покупают на одной бирже, и продают на другой», говорит Эдельман. «Другие покупают и продают на одной и той же бирже».

Вот упрощенная версия того, как работает этот процесс. Скажем, Форд хочет показывать рекламу потребителям, которые предположительно относятся к покупателям сегмента люксовых автомобилей – женщинам в возрасте от 35 до 60 лет, которые искали «Мерседес» в Гугл, лайкали истории о БМВ на Фейсбук, или просматривали страничку люксовых авто на About.com. В каждом из этих случаев, Форд или рекламное агентство которое он нанял, такое как Omnicom Group, может создать профили людей, которых они ищут и подключиться к бирже на которой рекламодатели покупают места на сайтах. Сайты отправляют информацию о свободном месте и своей аудитории. Когда Форд видит аудиторию, которую он ищет, он может поставить бид на покупку места на сайте. Если его бид оказывается лучшим, объявление о роскошном седане от производителя тут же появляется в заданном месте сайта. Вся сделка происходит за 100 миллисекунд или меньше.

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

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

В то время как, компания Google ограничивает участие в торгах только рекламодателями и их представителями, другие биржи не запрещают участие посредников. Отвечая на вопрос, будут ли они пытаться запретить участие арбитражеров на их биржах AppNexus, Microsoft, и Rubicon отказались от комментариев. Президент PubMatic Кирк Макдональд говорит, что его компания не будет блокировать посредников, потому что невозможно контролировать их деятельность на других биржах.

По мнению Magna Global научно-исследовательскому и медиа подразделению Interpublic Group (IPG), в этом году компании по всему миру потратят порядка 9,33 млрд. долл. на онлайн-рекламу. Хотя аукционы принесли эффективность ценообразования в бизнесе, компьютеризация происходит настолько быстро, что рекламные агентства стараются не отставать, говорит Мэтт Зайлер, главный исполнительный директор компании IPG Mediabrands.

Арбитражеры «могут искажать рынок и убирать эффективность, что мы предполагаем увидеть на торгах в режиме реального времени», говорит Маркус Пратт, дирктор по технологиям в Mediasmith. Также Пратт заметил, что его фирма покупала объявления на About.com по самым различным ценам на разных биржах и в конечном итоге он договорился с About.com напрямую, избежав публичных торгов. «Мы получили лучшие цены, чем когда мы просто работали на открытом рынке».

Хотя они и процветают сейчас, трейдеры говорят, что арбитражные возможности не всегда будет столь же широки, как сегодня. По данным исследовательской компании Маркетер, к 2016 году почти треть выставленных на аукцион объявлений в США будет продана на частных рынках, которые соединяют покупателя и продавца напрямую. Так в целях диверсификации бизнеса есть еще команда на западном побережье, которая занимается развитием инструментов, помогающим рекламодателям ориентироваться в мутном интернет мире и покупать места более эффективно.

from Bloomberg BusinessWeek

Почему супермассив данных никогда не заменит исследование рынка.

2014-10-31T11:52:30Z

Опубликовано в рамках конкурса

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

Ерунда.

Для начала, позвольте мне сделать необходимую ремарку. Я ни в коем случае не выступаю против супермассивов данных. На самом деле, я очень взволнован крупными и богатыми наборами данных, которые, мы надеемся, приведут к новым знаниям и интересным идеям. Моя точка зрения состоит в том, что супермассивы данных не являются панацеей. Они могут рассказать нам, что произошло в прошлом, и, возможно, вывести будущие события, но они имеют ограниченные возможности объяснить, ПОЧЕМУ что-то произошло. Без понимания ПОЧЕМУ, супермассивы данных не обладают значительной практической ценностью.

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

Не существует никаких сомнений, что колоссальный рост Facebook, был вызван Супермассивом данных. Каждое фото, лайк, комментарий, и так далее, которые вы делаете, собираются, берутся на анализ и анализируются, чтобы создать высоко персонализированный профиль каждого пользователя. С такой огромной сокровищницей персональных данных, какая возможная необходимость могла заставить Facebook обращаться к методам старой школы исследований?
Но, как сообщает Huffington Post, Facebook не только "регулярно опрашивает своих пользователей", но и создал панель обратной связи для подготовки данных для долгосрочных исследований, которые по утверждению многих скептиков уже давно ушли в прошлое. Несмотря на огромное количество пользовательских данных, Facebook видит ценность в непосредственном опросе своих пользователей.

Другим гигантом больших данных является Google, который объединяет личные данные из своих поисковых систем, электронной почты, карт, браузера и других продуктов, чтобы создать высокоточный портрет того, кто мы есть, с целью лучше таргетировать рекламу. С разнообразным и подробным объемом данных размером с гору Олимп, не говоря уже о команде супер-умных ученых, безусловно, Google не нуждается в том, чтобы задавать вопросы своим пользователям. Само упоминание о проведении таких исследований рынка, кажется таким старомодным, как телефон с диском.
На самом деле, в соответствии с thenextweb, Google опрашивал своих пользователей чтобы лучше понять, почему пользователи реагируют определенным образом на различную рекламу. Супермассивы данных могут рассказать Google, что пользователи делают (отключение звука в объявлении, закрытие рекламы на полпути, и т.д.), но они не могут объяснить, почему пользователи реагируют именно таким образом. Отсюда, полагаю, что потребность в традиционных исследованиях рынка никуда не исчезла и не исчезнет в ближайшем будущем.

Если понравилось, не забудьте сказать "спасибо" [blush]

О новом интерфейсе IMarketDataProvider

2014-09-25T21:47:11Z

Достаточно тихо прошло нововведение интерфейса IMarketDataProvider. Тем не менее, сама фича очень важна, так как она меняет использование самого старого класса - Security.

Как известно, класс Security, олицетворяющий собой финансовый инструмент, имеет просто огромное количество полей (классические OHLC, лучшие котировки, последную сделки, греки опционов и многое другое). Пользоваться этим получается достаточно удобно:

Код

// получение цены последней сделки
var lastTradePrice = sber.LastTrade == null ? (decimal?)null : sber.LastTrade.Price;

// получение открытого интереса по РИ
var oi = ri.OpenIntereset;

И чудесным образом подключение к торговой системе через XXXConnector обновляет эти данные. Но в этой красоте скрывается один серьезный недостаток. А что если у нас 2, или даже, 3, поключения (причем, некоторые из них могут быть вполне виртуальными, как HistoryEmulationConnector)? И все они транслируют данные по многим одинаковым инструментам. Какое подключение будет обновлять данные?

Ответ простой - все одновременно. И мы получаем кашу, если мы используем единые объекты для разных подключений. По-умолчанию, подключения создают отдельные объекты Security. Тогда перезапись данных невозможно. Но получается другая проблема - разные объекты для одного и того же инструмента.

В итоге родилась идея, чтобы хранить изменяющиеся поля в подключении (точнее, реализации IMarketDataProvider), а константные (код, дата экспирации, шаг цены и т.д.) оставить в классе Security.

Спешу сразу успокоить - по-умолчанию все работает в классическом режиме. При обновлении вам не нужно "доводить напильником" старый и проверенный код. Но чтобы получить возможность использовать один объект в разных подключения - просто включите соответствующие режимы. Вот как будет выкглядеть старые код на новый лад:

Код

// получение цены последней сделки
var lastTradePrice = myStrategy.GetSecurityValue<decimal?>(sber, Level1Fields.LastTradePrice);

// получение открытого интереса по РИ
var oi = myStrategy.GetSecurityValue<decimal?>(ri, Level1Fields.OpenIntereset);

Конечно же, это несколько сложнее, чем предыдущий код. Но тем самым будет упрощено взаимодействие с параллельным тестированием и работой стратегий. И да, в Студии нужно использовать, конечно же, последний вариант. Есть повод для осмысления и модернизации.

Многослойный персептрон! Грааль где то рядом!

2014-01-22T18:23:12Z

Начало здесь: http://www.stocksharp.co...--Vpiervyie-na-arienie/

Первая часть: Для тех, кто верит в нейросети
В вышеуказанном посте я описал работу персептрона, как он учится и торгует после обучения. Проблема в том, что я начитавшись постов в интернете сделал как все. То есть, собрал сеть, обучил, написал стратегию под сеть, и давай ее тестировать! Обучу на одних входных параметрах, тестирую стратеги, обучу на других, тестирую. И тут меня осенило! Когда сеть обучается идет подсчет ошибки, а что если вести параллельный подсчет еще и ошибки работы сети на данных не участвующих в обучении? После реализации чего, прогнав данные в которые я верил, окончательно разочаровался в персептроне. Но все по порядку.

Вторая часть: Что я поправил еще до этой идеи.
Убрал позорный график и вставил родной от S# .
Параметры персептрона теперь передаются в StatisticParameterPanel от S# .
Обучается параллельно 5 нейросетей с одинаковыми параметрами, но с разными первоначальными весами.
Сохраняется одна сеть на выбор пользователя, один раз при остановке обучения (раньше сохранялась при обновлении минимума).
Еще по мелочи, кнопки убрал, перегруппировал и тп.

Третья часть: Что я поправил после этой идеи.
Добавил еще график для вывода контрольной ошибки.
Ошибка считается теперь не среднеквадратичная, а абсолютная. Так легче для понимания графика. Например, на рисунке видно, что образов для обучения 804 это значит, что сети предоставлено 804 единиц, минус единиц, и нулей. Если сеть на каждый образ выдаст ноль, то суммарная ошибка будет равна 804. Что мы и видим на нижнем графике рисунка, вначале обучения ошибка сети равна 804.
Контрольная ошибка считается также, как и ошибка обучения, но на следующий день после последнего дня обучающей последовательности. И НИКАКИМ ОБРАЗОМ НЕ ВЛИЯЕТ НА ОБУЧЕНИЕ СЕТИ. На рисунке видно, что количество образов проверки 161, это значить что если сеть не нашла закономерность, то контрольная ошибка будет колебаться вокруг 161. По логике вещей если сеть нашла закономерность, то контрольная ошибка всех 5 сетей должна устремиться вниз. И дойти хотя бы до 100-110. Но такого я не видел. Прошу если кто-то этого добьется, опубликуйте скирин окошка, верните веру. [biggrin]
В выложенном варианте входную последовательность, и эталон я менять не стал(ну не выкладывать же грааль [lol]). Все как первом моем посте на эту тему. И лежит там же.

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

Вот и все!
Всем спасибо за внимание! Жду отзывов, и лайков! [biggrin]

Один день из жизни Ri. Баланс объема сделок.

2013-12-24T22:23:42Z

В предыдущей статье мы расмотрели, как выглядит рынок на микроуровне (ордер лог сделок). На этот раз мы углубим наш анализ, в следующем направлении. Как известно на рынке действует простое правило, если кто-то продает значит кто-то это покупает и наоборот, таким образом если сложить объемы всех сделок на покупку(+объем) и продажу(-объем) то получится ноль, то есть существует некоторое соотношение "баланса" которое никогда не нарушается. Как нам это может помочь в анализе? Очень просто, если классифицировать весь входящий поток сделок по некоторым группам, мы можем увидить как изменяется динамика баланса (поглащенного объема) между разными группами. Самый простой вариант - классифицировать сделки по группам, используя объем выставленный в заявке которая породила сделку, учитывая наш предыдущий анализ распределния объема, выберем следующую сегментацию на три группы по объему заявки 1-10, 10-100, 100-10000. Затем просуммируем выставленный объем на покупку со знаком '+', на продажу со знаком '-' для каждой из групп таким образом получим временной ряд отображающий изменение баланса объема между группами (если сделки происходили внутри группы, то они не приведут к изменению). Рассмотрим один из графиков построенных указанным способом(с добавлением графика цены Ri).

Как видно из графика, хотя динамика Ri и не определяется полностью динамикой группы крупных трейдеров (объем сделки 100-10000), видно что большинство крупных структур в цене движения актива (в том числе небольшие спайки) вызываются именно ей, в то время как остальные две более мелкие группы (в том числе HFT) выступают абсорберами этого дисбаланс сделок.

Рассмотрим такой же график за другой день.

Как видно из графика, в этот день взаимная динамика носит иной характер, баланс сделок группы (100-10000) носит более размытый по времени характер, и корреляция с активом возникает лишь в моменты возникновения более интенсивных "спайков" объема, в остальное время динамика скорее всего определяется внешними факторами.

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

Продолжение следует.

Рассказ нашего ученика 2

2013-12-18T00:50:55Z

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

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

Ниже буду приводить скриншоты моей последней версии «Анализатора», более раннюю версию можно скачать с серверов S#. Просто опишем, что из себя представляет система визуализации стратегий.

Задаем диапазон тестирования, таймфрейм и тестируемый инструмент. Как дополнительно, но не обязательно можно задать комиссию, начальный депозит и др. настраиваемые параметры.

Строим свечной график, также выводим индикаторы. Снизу строим график Эквити. В данном примере для оценки стратегии я использую свой расчет Профита. В стандартной версии графика PnL от S# используется немного другой вариант, более приспособленный для торговли в реальном времени с расчетом вариационной маржи.

Выводим сделки на график в виде стрелок. Зеленая стрелка покупка, красная продажа. Это стандартная функция. Прикрутить к коду не сложно, главное округлить время сделки до времени свечки, а то она может выставиться некорректно.

Что нам еще нужно? Не плохо бы знать, что и в какой последовательности делала наша стратегия. Нам нужно Логирование! В стандартных версиях полно разных видов окон логирования, но я как всегда не ищу легких путей и сделал свое логирование на базе ListView из WPF C#.

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

Статистика

Очень важно перед запуском стратегии для реальной торговли на бирже проверить ее на работоспособность – протестировать. Как нам узнать какая стратегия хорошая, а какая плохая? Оказывается итоговая прибыль в конце тестирования не единственно важный показатель нашего алгоритма. Для полной картины нам нужно изучить статистические показатели нашей стратегии.

Основные формулы для расчета показателей стратегии:
1. Profit factor (PF)
Рассчитывается как отношение за определённый период суммы всех прибыльных сделок к сумме всех убыточных с положительным знаком. Большее значение соответствует меньшей вероятности разорения.
Profit Factor = [Сумма прибылей всех прибыльных сделок] / [Сумма прибылей всех убыточных сделок]

2. Maximum Intraday Drawdown (MIDD)
Максимально Нарастающий Убыток (MIDD — Maximum Intraday Drawdown). Он обозначает самую большую финансовую яму, в которую попадала наша система.
Максимальный нарастающий убыток – это глубина максимальной просадки за период.

3. Вероятность выигрыша %W (P)
%W(P) вероятность выигрыша (отношение количества выигрышных сделок к общему их количеству).
* вероятность выигрыша > 0,5.

4. Математическое ожидание M[X]
Математическое ожидание — понятие среднего значения случайной величины в теории вероятностей. В зарубежной литературе обозначается через Е[X], в русской M[X]. В статистике часто используют обозначение μ.
Наиболее распространенные варианты расчета:
1) M[X] Математическое ожидание = вероятность выигрыша * средняя величина выигрыша + вероятность проигрыша * средняя величина проигрыша (в качестве результата прирост на 1 сделку в абсолютных величинах)
2) M[X] Математическое ожидание (1+( средняя величина выигрыша / средняя величина проигрыша))* вероятность выигрыша -1 (в качестве результата вероятность в % получения прибыли за период)
* M[X] > 0,6 верно для варианта 2.

5. Фактор восстановления (RF)
RF (фактор восстановления, restoration factor) = отношение прибыли за период (Profit) к максимально нарастающему убытку (MIDD) за тот же период.
* при тестировании RF должен быть > 2

6. Стандартное отклонение (σ)
Стандартное отклонение σ или SD (sigma) — это широко используемая мера разброса или вариабельности (изменчивости) данных. Стандартное отклонение популяции определяется формулой:
SD= [S(xi-m)2/N]1/2, где m — среднее популяции, N — размер популяции.

7. Z-счет
Z-счет позволяет определить эффективность торговой системы одной цифрой, предоставляя более точные результаты при сравнении с другими ТС. Кроме того, положительный либо отрицательный результат Z-счета несет в себе дополнительную информацию об особенностях использования взятой торговой системы.
Собственно, формула вычисления Z-счета имеет вид:
Z-счет = (N*(R — 0.5) — X)/((X*(X — N))/(N -1))^(1/2)
N – общее количество сделок;
X – 2*количество прибыльных сделок*количество убыточных сделок;
R – количество серий (сколько раз после прибыльной сделки шла убыточная и наоборот);
^(1/2) – это квадратный корень.
Для определения Z-счета необходимо иметь данные как минимум по 30 сделкам. Положительный либо отрицательный Z-счет несет в себе дополнительную информацию:
1) Положительный Z-счет означает, что практически после каждой прибыльной сделки следует убыточная, т.е. торговая система склонна к чередованию. И, чем больше число Z-счета, тем чаще происходит чередование. Основываясь на этом, следует после каждой убыточной сделки увеличивать размер лота (т.к. следующая сделка будет прибыльной), а после прибыльной – уменьшать лот.
2) Отрицательный Z-счет означает, что ТС имеет последовательные серии как прибыльных, так и убыточных сделок. Эти данные вырисовывают следующий сценарий – если система склонна к сериям, то после первой убыточной сделки следует прекратить торговлю и войти в рынок снова только после первой прибыльной сделки. Мы пропускаем одну прибыльную сделку, но, при этом, минуем серию убыточных.

Прочая статистическая информация:
8. Общее число сделок.
9. Число прибыльных сделок.
10. Число убыточных сделок.
11. Средняя прибыль от сделки.
12. Средний убыток от сделки.
13. Максимальная прибыль.
14. Максимальный убыток.

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

Подробнее о тестировании и простой оптимизации

Ранее мы рассмотрели на примерах как можно визуализировать свою стратегию:

И рассчитать основные ее показатели:

Но все эти приложения имеют графическую оболочку (англ. Graphical user interface, GUI), что сказывается на производительности таких приложений. Для того чтобы тестировать много стратегий и очень быстро нам нужно использовать более производительную архитектуру приложений.

Например, консольные приложения, хотя некоторые профессионалы умудряются обходиться вообще без GUI.

Рассмотрим простое консольное приложение для тестирования стратегий методом перебора.

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

На примере стратегии из двух пересекающихся SMA (Simple Moving Average, простое скользящее среднее) постараемся выбрать лучшие варианты из сочетания длин периодов «короткой» и «длинной» скользящих средних.

Для этого создадим диапазон параметров «длинной» SMA от 20 до 120 и выберем шаг для этого диапазона равным 1. Итоговые данные сохраним в одномерном массиве {20, 21, 22, … ,120}. Аналогично для «короткой» SMA с диапазоном от 5 до 20 с тем же шагом 1 создадим одномерный массив {5, 6, 7, …, 20}.

Теперь сформируем массив всех возможных вариантов стратегий сочетанием значений массива «длинной» и «короткой» SMA. Получим следующий массив всех вариантов параметров нашей стратегии: {{20, 5}, {20, 6}, …, {20, 20}, {21, 5}, …, {120, 19}, {120, 20}}. Итого 1500 вариантов нашей стратегии. Не мало. Поэтому нам так важна скорость тестирования.

В S# есть простые примеры как провести такое тестирование. Я брал исходные параметры наших SMA из массива параметров стратегий и по очереди в цикле их тестировал. В итоге, после каждого теста получал массив []MyTrades в котором хранились данные времени совершения сделок, их направление (Покупка или Продажа), объем сделок (количество контрактов в сделке) и цены сделок за временной период тестирования.

В конце мы получили число массивов с результатами тестирования равное числу всех возможных параметров нашей стратегии. Сохраняем (сериализуем в бинарный файл) все наши параметры и результаты тестирования. Открываем эти файлы в рассмотренном ранее «Анализаторе», рассчитываем по этим данным статистику и получаем итоговую таблицу с результатами тестирования. Сортируем данные, например, по матожиданию и анализируем результаты. При этом можем сразу визуализировать заинтересовавшую нас стратегию.

Примерно так проходит тестирование и оптимизация стратегий. Но оптимизация методом перебора зарекомендовала себя как неэффективная и ресурсоемкая при больших объемах данных. В следующей статье мы рассмотрим другие более производительные варианты оптимизации стратегий.

Всем восходящего тренда! С уважением, Bond.
Бонд наш ученик!