Выполнение лимитированных заявок в HistoryTestTrader
Atom
17.02.2011


Попробовал выставлять лимитированные заявки: правильно ли я понял, что они выполнятся при условии, если цена ask из стакана(для заявки на покупку) опускается до цены ордера, и по цене ask (часто отличной от цены в ордере)?

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

Заранее спасибо



Спасибо:



Именинники: o.cheban82, NLRR

< 1 2 3 4 5  >
Mikhail Sukhov

Фотография
Дата: 21.02.2011
Ответить


Juri Перейти
Это происходит в реальности. Ну если в модельных терминах, то наверно, при сохраненном стакане.


Я не понял из ответа, в тот момент, который вы описывали выше, стакан был подгружен из истории или сгенерирован?
Спасибо:

andy

Фотография
Дата: 21.02.2011
Ответить


Mikhail Sukhov Перейти

Ок, мне кажется идет банальное непонимание друг друга в плане терминологии. Что такое матчинг? Это процесс сопоставления заявки со стаканом.


Ну взаимное понимание не сразу приходит Smile

Да, матчинг - это процесс сопоставления заявки со стаканом. А если еще точнее - сопоставления двух заявок.

Раз заявки исполняются по стакану (что и произошло по историческим данным), то наша заявка с новой ценой, которая будет больше цены по исторической заявке и меньше цены ask, будет удовлетворена, т.к. наша цена для продавца выгоднее, чем историческая. Другими словами: раз продавец продал за 90, то за 100 тем более продаст)) Этот вариант матчинга сейчас и не учитывается.
Спасибо:

Mikhail Sukhov

Фотография
Дата: 21.02.2011
Ответить


andy Перейти
Да, матчинг - это процесс сопоставления заявки со стаканом. А если еще точнее - сопоставления двух заявок.


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

andy Перейти

Раз заявки исполняются по стакану (что и произошло по историческим данным), то наша заявка с новой ценой, которая будет больше цены по исторической заявке и меньше цены ask, будет удовлетворена, т.к. наша цена для продавца выгоднее, чем историческая. Другими словами: раз продавец продал за 90, то за 100 тем более продаст)) Этот вариант матчинга сейчас и не учитывается.


Ок, теперь стало понятнее. Разберем две ситуации, когда стакан сохранен и когда он создается из воздуха:

1. При загруженном стакане тиковая сделка вообще слабо влияет на ситуацию, так как стакан является более точными данными, и если сделка тиковая ему противоречит, то скорее всего проблема в сделке, а не в стакане. Например, это может быть из-за того, что точность сделок секундная, в то время как стакан оперирует миллисекундами. Верить сделке не стоит, поэтому ее просто отбрасываем из нашего уравнения. И так, у нас осталась только наша заявка на покупку по 100 + загруженный стакан с лучшим бидом в 90 и офером в 110. Заявка выполнена не будет, что вполне логично, так как текущая ситуация на рынке не способствует покупке по 100.

2. Стакан был сгенерирован на основе тиковой сделки в 90. Отправной точкой будет цена в 90. Стакан будет сгенерирован с лучшим бидом в 90 - random и лучшим офером 90 + random (в версии 3.0.6 по другому, но на данную ситуацию это не влияет). Скорее всего, если шаг цены равен 1, заявка исполниться.

Вопрос, что не так в этих двух ситуациях и как бы Вы это изменили?
Спасибо:

Juri

Фотография
Дата: 22.02.2011
Ответить


Mikhail Sukhov Перейти

1. При загруженном стакане тиковая сделка вообще слабо влияет на ситуацию, так как стакан является более точными данными, и если сделка тиковая ему противоречит, то скорее всего проблема в сделке, а не в стакане. Например, это может быть из-за того, что точность сделок секундная, в то время как стакан оперирует миллисекундами. Верить сделке не стоит, поэтому ее просто отбрасываем из нашего уравнения. И так, у нас осталась только наша заявка на покупку по 100 + загруженный стакан с лучшим бидом в 90 и офером в 110. Заявка выполнена не будет, что вполне логично, так как текущая ситуация на рынке не способствует покупке по 100.

2. Стакан был сгенерирован на основе тиковой сделки в 90. Отправной точкой будет цена в 90. Стакан будет сгенерирован с лучшим бидом в 90 - random и лучшим офером 90 + random (в версии 3.0.6 по другому, но на данную ситуацию это не влияет). Скорее всего, если шаг цены равен 1, заявка исполниться.

Вопрос, что не так в этих двух ситуациях и как бы Вы это изменили?


Россмотрим по-порядку.
1. "так как стакан является более точными данными, и если сделка тиковая ему противоречит, то скорее всего проблема в сделке, а не в стакане."

Как раз наоборот.
Файл всех сделок является вполне достоверным. И там отражены ВСЕ сделки, а не только те что мы видели.
Стакан же всего лишь снимок состояния, и что было между этими снимками мы не знаем. Чтобы построить достоверный стакан нужно иметь файл всех заявок, а такого я не встречал (наверо на бирже то есть).

"Например, это может быть из-за того, что точность сделок секундная,"
Вообще странный аргмент,
а в частноси возмите например все сдели с биржи http://ftp.rtsnet.ru/pub...ory/F/2011/FT110221.zip
там время с точностью до мсек.
А вот получить стакан с милисекудной точностью мне не удалось. QUIK выдает стакан как раз 1 раз в сек.

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

Итак полностью не согласен с п 1.

теперь посмотрим на 2 пункт.

Вроде бы генерация стакана по Вашему алгоритму дает тот результат что и требовалось -
наша лимитная заявка исполнена по её цене (100).

Тогда такой вопрос. По какой цене будет исполнена Рыночная заявка на покупку, если реальный Ask=110, а сгенерированный например равен 99?

Спасибо:

Mikhail Sukhov

Фотография
Дата: 22.02.2011
Ответить


Juri Перейти
Как раз наоборот.
Файл всех сделок является вполне достоверным. И там отражены ВСЕ сделки, а не только те что мы видели.
Стакан же всего лишь снимок состояния, и что было между этими снимками мы не знаем.


Стакан меняется чаще чем сделки. Плюс сделки происходят на основе состояния стакана, и ничего более. Это моем имхо.

Juri Перейти

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


А то что отдается в стакане не подходит? Это все те же заявки, только ограниченные по глубине. Сверх установленной глубины стакан и не нужен. Все равно максимально достоверно можно проверить на истории лот в несколько контрактов (а это значит 2-3 котировки всего нужны). Больше, это уже движение рынка, а такого на истории быть не должно.

Juri Перейти

"Например, это может быть из-за того, что точность сделок секундная,"
Вообще странный аргмент,
а в частноси возмите например все сдели с биржи http://ftp.rtsnet.ru/pub...ory/F/2011/FT110221.zip
там время с точностью до мсек.


Посмотрел файл. Примерно 1 к 10 имеет миллисекундную точность. Остальное все в секундах. Подозреваю, что это какие-то особые сделки.

Juri Перейти

А вот получить стакан с милисекудной точностью мне не удалось. QUIK выдает стакан как раз 1 раз в сек.


Если брать РТС, то с переходом на Плазу стаканы начали обновляться значительно быстрее.

Juri Перейти

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


Ок, я добавил метод HistoryTestTrader.ProcessData. В нем можно перегрузить логику матчинга заявок. Не будет достаточно, еще расширю.

Juri Перейти

Тогда такой вопрос. По какой цене будет исполнена Рыночная заявка на покупку, если реальный Ask=110, а сгенерированный например равен 99?


Реальный - это как получилось? Из сделки или из сохраненного снимка стакана?
Спасибо:

Juri

Фотография
Дата: 22.02.2011
Ответить



Я имел ввиду, как будет исполнена такая заявка в при сушествующем методе матчинга?




Спасибо:

pyhta4og

Фотография
Дата: 22.02.2011
Ответить


Написал примитивный визуализатор тиков-стаканов что приходят через ITrader.

вот картинка полученная через Smart (на демосчете)



Красные столбцы - аски, зеленые - биды.
Сверху над асками - голубое время получения (LastChangeTime) в формате сек.миллисек
Трейды - просто цифры. Для трейдов таймстемп с биржи.

Что видно.

1) самое важное. Когда приходили трейды помеченные по времени как 23.00 (повышающаяся лесекнка), стаканы с бидами=цене трейдов
не приходили. Поэтому если мы имитируем заявку помеченную на рисунке как <1> по тем стаканам что на рисунке,
то она НЕ ВЫПОЛИТСЯ. Нет бидов по которым сгенерировались сделки на рисунке. Точнее, в природе на бирже они были,
но нам их не передали. Передали сделки и пустой "стакан после"

Это аргумент в пользу Juri
Цитата:

Файл всех сделок является вполне достоверным. И там отражены ВСЕ сделки, а не только те что мы видели.
Стакан же всего лишь снимок состояния, и что было между этими снимками мы не знаем. Чтобы построить достоверный стакан нужно иметь файл всех заявок, а такого я не встречал (наверо на бирже то есть).


2) стакан помеченный как "стакан после" передался смарттрейдом ДО того как передались сделки которые привели к такому стакану.
Визуализатор рисует все в порядке получения событий NewQuotes, NewTrades из ITrader.




Далее. Давайте рассмотрим вопрос как имитировать исполнение наших фиктивные лимитки в случае неполной (редкой) информации по стакану.

Т.е. входные данные:
1) Срезы реального стакана. Поставляются нам с периодом 1 секунда и не отражают промежуточных состояний стакана
2) Реальные сделки. Поставляются нам все, но в смарте могут запаздывать относительно срезов стакана.
3) Наши фиктивные лимитки.

По этим данным надо понять, исполнятся фиктивные лимитки или нет.

Тут несколько случаев:
Случай А. Фиктивная лимитка при выставлении матчится с последним срезом реального стакана. Проблем нет, сразу ее исполняем.
Случай Б. Новый срез реального стакана матчится с выставленной ранее фиктивной лимиткой. Тоже проблем нет, исполняем

Эти два случая уже я так понял реализованы в S#

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

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



Если кому надо сорсы примера с визулизатором закачал http://www.box.net/shared/g8k7452gdr
Спасибо:

Mikhail Sukhov

Фотография
Дата: 23.02.2011
Ответить


Ок, хороший анализ. Но есть к нему претензии:

1. Стакан обновляется чаще, чем раз в секунду. У Смарта. И у Квика. Можно в принципе простейший тест написать вывода в консоль при событие QuotesChanged. Почему на картинках обновление секундами? Хотя завтра можно проверить, вдруг у ИТ случились какие-то проблемы.

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

3. Уже сейчас есть метод HistoryTestTrader.IsMarketDepthChangeRequired. Он сделал как раз для случая, когда у нас отсутствуют стаканы на длительный период. Как тот, который вы указали на скрине. В этом методе как раз и используется та самая ликвидность инструмента, что передается в конструктор HistoryTestTrader через securitySettings. И стакан генерируется на основе тиковых сделок.

Собственно, о чем спор? Верить или не верить стакану? Я думаю, что ему надо верить, и сохраненный стакан только улучшает качество тестирования. Но я это не проверял.

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

pyhta4og

Фотография
Дата: 24.02.2011
Ответить


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

Вы настояли что исполнять надо трейды путем матчинга со стаканом и только со стаканом.

Я привел пример, когда данных о реальном стакане недостаточно для корректного исполнения заявки. Это на картинке обозначено как неисполнение заявки <1>. Именно, заявка селл по цене 184565 не будет исполнена симуляторром, хотя поток сделок поднявшийся с 184525 до 184585 должен был к этому привести

Вы сказали что есть генерация стакана когда он отсутствует длительное время через IsMarketDepthChangeRequired.

Это не совсем так

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

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



Спасибо:

Mikhail Sukhov

Фотография
Дата: 24.02.2011
Ответить


pyhta4og Перейти
Трейды из рисунка пришли в один момент - с временем 23сек. Поэтому генератор стаканов вызовется только после всех этих трейдов. Т.е. если у 5 трейдов подряд абсолютно одинаковое время, то генератор стакана невозможно вызвать после каждого трейда - только после всей группы.


Ок, тогда я видимо не совсем Вас понял. Вернемся к картинке. По какому принципу голубым вверху проставляются цифры? Я думал это LastChangeTime, но так как там нет стаканов, то получается что это даты чего-то другого? По всей видимости время сделок. Тогда мне не понятно особенность периода в 23-ей секунде.

upd:

Так я кажется понял. Есть два стакана, на момент 22.24 и 23.40. Между ними были сделки по ценам, отмеченные лесенкой. Остался такой вопрос. Заявка <1> была выставлена в какой момент?
Спасибо:
< 1 2 3 4 5  >

Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy