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

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

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

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

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

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



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

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?

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



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



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



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



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



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

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

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

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



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

Что видно.

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

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


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




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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

upd:

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