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

Там миллисекунды будут совершенно не те (даже секунды будут не те). Это вполне естественно, так как...

2011-03-01T15:35:11Z

Mikhail Sukhov

Juri

Mikhail Sukhov

Там миллисекунды будут совершенно не те (даже секунды будут не те).

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

Тогда LastChangeTime для сделки не будет работать, как предлагал pyhta4og.

Как раз наоборот. Раз сделки приходят более-менее быстро, то как раз введение LastChangeTime для сделок позволит на истории моделировать более реалистично, потому что по этому LastChangeTime можно хоть как-то синхронизировать записанные стаканы и сделки.

Вот простая ситуация. Я тестирую в реале. У меня в стратегию приходят стаканы и сделки в определенной последовательности. И те и другие опаздывают, но это РЕАЛЬНОСТЬ.

Я записываю все эти данные гидрой. Точнее пытаюсь

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

Я считаю что на истории данные надо прогонять по одной и той же временной метке. А сейчас единственный вариант - по LastChangeTime (локальному времени получения). Со всеми миллисекундами.

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

2011-02-21T05:54:24Z

Mikhail Sukhov

Проблема описанная выше идет как раз от генерации стакана. Сейчас он не совсем правильно генерируется, и поступило предложение как его переделать. Предлагаю обсуждать уже здесь http://stocksharp.com/posts/m/6090/#post5374

Хорошо, можно и пообсуждать...
Тогда подскажите, где можно познакомиться с подробным описанием существующего алгоритма генерации стакана?

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

2011-02-20T17:35:57Z

andy

Как может изменение MarketDepthGenerator повлиять, если имеются исторические стаканы или проверка идет по реал-таймовым данным?

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

Ок, мне кажется идет банальное непонимание друг друга в плане терминологии. Что такое матчинг? Это процесс сопоставления заявки со стаканом. Тут не важно, история это или рел тайм или эмуляция - сопоставление идет по стандартной схеме, которой пользуются те же биржи: есть стаканы, есть заявка, если она пересекается с котировками, уменьшается ее баланс. Это менять смысла не имеет, потому что к описанной выше проблеме не имеет совершенно никакого отношения. Проблема описанная выше идет как раз от генерации стакана. Сейчас он не совсем правильно генерируется, и поступило предложение как его переделать. Предлагаю обсуждать уже здесь http://stocksharp.com/posts/m/6090/#post5374

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

2011-02-22T15:43:11Z

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

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

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

Что видно.

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

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

Цитата:

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

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

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

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

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

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

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

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

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

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

Здравствуйте! Время скачет +-4 секунды от указанного в сделке. С отставанием времени сделки понятно ...

2011-03-21T09:02:58Z

Juri

Здравствуйте!

Иванов Андрей

Время скачет +-4 секунды от указанного в сделке. С отставанием времени сделки понятно -- лаги самой биржи, лаги Quik, лаги сети. Откуда берётся убегание вперёд, даже не представляю =)

Да уж, просто мистика )
Может просто на Вашем компьютере время установлено не несколько секунд (где-то 5-6) вперед от биржи?

Все современные системы по умолчанию синхронизируют время с часами в интернетах.
Плавание идёт в течение дня, сомневаюсь, что у меня какой-то уникальный глюк, заставляющий гулять время в таком диапазоне на таком маленьком интервале.

Цитата:

Иванов Андрей

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

Просто любопытно, а почему грустно?

Потому что они искажают реальность =)

Цитата:

Иванов Андрей

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

Здесь немного не понял...
Для моделирования исполнения вашей сделки вы используете только файл всех сделок?
А тогда какие цены ("беру либо из сделки лога, либо из заявки") когда берете?

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

Здравствуйте! Время скачет +-4 секунды от указанного в сделке. С отставанием времени сделки понятно ...

2011-03-20T11:10:07Z

Здравствуйте!

Иванов Андрей

Просто любопытно, а почему грустно?

Иванов Андрей

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

С этим вполне согласен...

Про время и про стаканы. Я с декабря где-то пишу логи сам. До декабря тоже писал, разница в том, что...

2011-03-20T06:49:22Z

Про время и про стаканы.

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

Время скачет +-4 секунды от указанного в сделке. С отставанием времени сделки понятно -- лаги самой биржи, лаги Quik, лаги сети. Откуда берётся убегание вперёд, даже не представляю =) Писать начал в качестве эксперимента, просто любопытно было. Использовать планирую для разделения сделок по блокам, чтобы они в эмулятор приходили такими же пачками, как и в реальности, потому что с тиками работать грустно.

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

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

Сохранённые стаканы искажают картину мира очень сильно. Потому что это снимки с интервалами, а не то, что происходит на бирже. Я на стаканы не смотрю даже когда руками торгую (возможно, просто не знаю, как их использовать, я просто программист, а не трейдер). Но про это вы вроде уже и сами договорились =)

Пишу не для спора или пожелания всё переделать. Может быть будет любопытно ещё одно мнение.

РТС-Стандарт в этой истории (http://ftp.rtsnet.ru/pub...ory/F/2011/FT110221.zip) нет похоже А что за...

2011-03-19T07:17:30Z

pyhta4og

РТС-Стандарт в этой истории (http://ftp.rtsnet.ru/pub...ory/F/2011/FT110221.zip) нет похоже

А что за разбиение такое на FE TE FT?

РТС-Стандарт в этой истории (http://ftp.rtsnet.ru/pub...ory/F/2011/FT110221.zip) нет похоже

2011-03-17T15:24:37Z

РТС-Стандарт в этой истории (http://ftp.rtsnet.ru/pub...ory/F/2011/FT110221.zip) нет похоже

"Например, это может быть из-за того, что точность сделок секундная," Вообще странный аргмент, а в ...

2011-03-13T21:36:56Z

Mikhail Sukhov

Juri

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

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

Вообщем, не так я смотрел. Я смотрел через Excel, а надо было через Notepad. В результате, все увидел. Буду переделывать в 3.1.[blush]

Ну вот нас уже двое. Мне кажется это уже повод на то чтобы фиче-реквест с введением Trade.LastChange...

2011-03-04T14:38:38Z

Ну вот нас уже двое.

Мне кажется это уже повод на то чтобы фиче-реквест с введением Trade.LastChangeTime был рассмотрен ;)

И те и другие опаздывают, но это РЕАЛЬНОСТЬ. Но у них разная скорость запаздывания. У сделок она бол...

2011-03-04T10:21:15Z

Mikhail Sukhov

pyhta4og

И те и другие опаздывают, но это РЕАЛЬНОСТЬ.

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

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

И те и другие опаздывают, но это РЕАЛЬНОСТЬ. Но у них разная скорость запаздывания. У сделок она бол...

2011-03-01T16:49:31Z

pyhta4og

И те и другие опаздывают, но это РЕАЛЬНОСТЬ.

Там миллисекунды будут совершенно не те (даже секунды будут не те). Это вполне естественно, так как...

2011-02-28T18:47:55Z

Juri

Mikhail Sukhov

Там миллисекунды будут совершенно не те (даже секунды будут не те).

Тогда LastChangeTime для сделки не будет работать, как предлагал pyhta4og.

Это еще хуже. Сделки приходят блоками и даже реже, чем секунда. Это не совсем так. Вот небольшой фра...

2011-02-27T16:23:44Z

Mikhail Sukhov

Это еще хуже. Сделки приходят блоками и даже реже, чем секунда.

Это не совсем так.
Вот небольшой фрагмент записи файла всех сделок сделанной мной через API QUIK.
Последнее поле это локальное время получения пакета сделок.

RTS-3.11,11:45:03,185820,1,Купля,275871384,24.02.2011 13:45:04.940
RTS-3.11,11:45:03,185835,2,Купля,275871399,24.02.2011 13:45:05.065
RTS-3.11,11:45:03,185845,1,Купля,275871400,24.02.2011 13:45:05.065
RTS-3.11,11:45:03,185830,2,Купля,275871402,24.02.2011 13:45:05.237
RTS-3.11,11:45:03,185825,1,Продажа,275871407,24.02.2011 13:45:05.237
RTS-3.11,11:45:03,185825,1,Продажа,275871408,24.02.2011 13:45:05.237
RTS-3.11,11:45:04,185830,2,Купля,275871420,24.02.2011 13:45:05.643
RTS-3.11,11:45:04,185830,1,Купля,275871421,24.02.2011 13:45:05.643
RTS-3.11,11:45:04,185825,1,Продажа,275871427,24.02.2011 13:45:05.643
RTS-3.11,11:45:04,185825,6,Продажа,275871431,24.02.2011 13:45:05.862
RTS-3.11,11:45:04,185825,5,Продажа,275871436,24.02.2011 13:45:05.862
RTS-3.11,11:45:04,185825,1,Продажа,275871437,24.02.2011 13:45:05.877
RTS-3.11,11:45:04,185820,1,Продажа,275871440,24.02.2011 13:45:05.877
RTS-3.11,11:45:04,185815,1,Продажа,275871441,24.02.2011 13:45:05.877
RTS-3.11,11:45:04,185815,2,Продажа,275871442,24.02.2011 13:45:05.877
RTS-3.11,11:45:04,185815,2,Купля,275871448,24.02.2011 13:45:05.877
RTS-3.11,11:45:04,185810,3,Продажа,275871449,24.02.2011 13:45:05.877
RTS-3.11,11:45:04,185810,3,Продажа,275871450,24.02.2011 13:45:05.877
RTS-3.11,11:45:04,185815,1,Купля,275871452,24.02.2011 13:45:06.205

Как видно за одну секунду пришло 5 пакетов со сделками. Вполне неплохо.

Mikhail Sukhov

Там миллисекунды будут совершенно не те (даже секунды будут не те).

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

2011-02-25T12:51:36Z

pyhta4og

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

Это еще хуже. Сделки приходят блоками и даже реже, чем секунда. Там миллисекунды будут совершенно не те (даже секунды будут не те).

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

2011-02-25T11:57:54Z

Цитата:

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

Цитата:

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

Тут получается такой вопрос: Давать или не давать стратегии торговать в середине потока сделок датированных на бирже одной и той же секундой?
Замечу, ведь в одной секунде могут и два маркетных ордера оказаться, один как на рисунке - жирный на покупку, второй - не менее жирный на продажу. И тогда получится лесенка вверх-лесенка вниз. И все "в один и тот же миг". Я полагаю у этих лесенок будет отличаться только время получения из смарта. Что-то типа первый набор ордеров 23.20 второй набор 23.50

Было бы разумным раз у стаканов у нас LastChangeTime - это время получения, добавить и трейдам аналогичное LastChangeTime - то же время получения и понаблюдать на картинке как группируются эти времена при "движухе". Тогда можно выработать эвристику деления потока сделок на отдельные неделимые рыночные ордера.

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

На самом деле и это все бесполезно. В базу же для трейдов только Time пишется. У лесенки Time=23.00 - биржевое, а у стаканов ей соответствующим LastChangeTime=24.35 - локальное. В HistoryTester соответственно все перепутается и промежуточные стаканы будут генерироваться между не теми реальными. Потому что пометку с биржи какому биржевому времени соответствует данный стакан нам не передают в отличие от сделок.

Цитата:

Предположим мы одним из предложенных выше способов сгенерировали стакан.
Он будет отличаться от реального стакана, изображенного на рисунке.
В данном случае, в момент сразу после 23.00 (то есть после прошедших в 23.00 сделок), скорее всего биды в сгенерированном стакане будут стоять выше, чем в реальном стакане.
Для определенности, пусть например это будет 184560.
И в этот самый момент мы выставляем на нашу виртуальную биржу (то есть тестер) виртуальную же рыночную заявку на продажу с минимальным объемом.
В нашем тестере она выполнится по цене 184560, а в реальности она бы выполнилась по цене 184500.
Разница слишком существенна для быстрых и скальперских стратегий.

Значит все еще хуже. Как не генерируй промежуточные стаканы по трейдам они будут неправильными.
Вывод - эмулятор должен явно использовать сделки помимо стаканов для матчинга. И эти сделки надо синхронизировать со стаканами. И сделать это можно только записывая в базу время прихода сделок аналогично LastChangeTime для стаканов.

Как-то все сложно получается :(

Ок, теперь понял что к чему... Да, тут наверное, самым правильным решением было бы уменьшения интер...

2011-02-24T17:56:51Z

Mikhail Sukhov

Ок, теперь понял что к чему... Да, тут наверное, самым правильным решением было бы уменьшения интервала генерации стакана до нескольких раз в секунду, и эмуляции миллисекунд у тиков. Мне это видится как отдельная опция у HistoryTestTrader для генерации тиков (тоесть, я сугубо против записывать сэмулированные миллисекунды в файл, так как это нереальные данные). Как сейчас можно это сделать (на выбор):

1. Можно перегрузить метод HistoryTestTrader.ProcessData, и в нем сгенерировать равномерно миллисекунды для стакана.
2. Создать наследника MarketDepthGenerator, который бы по тикам генерировал стакан. Генерация бы происходила с учетом этих виртуальных миллисекунд. Мне кажется, это даже лучще, так как не модифицируются объекты Trade.

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

И еще.
Попробую на примере, который очень наглядно изображен на рисунке задать свой вопрос второй раз и чтобы сэкономить время сам же на него и отвечу [smile]
Далее идут утверждения, соответствующие моему пониманию работы модели биржи, которая реализована в тестере.
Не исключено, что я не прав - тогда опровергните.
Предположим мы одним из предложенных выше способов сгенерировали стакан.
Он будет отличаться от реального стакана, изображенного на рисунке.
В данном случае, в момент сразу после 23.00 (то есть после прошедших в 23.00 сделок), скорее всего биды в сгенерированном стакане будут стоять выше, чем в реальном стакане.
Для определенности, пусть например это будет 184560.
И в этот самый момент мы выставляем на нашу виртуальную биржу (то есть тестер) виртуальную же рыночную заявку на продажу с минимальным объемом.
В нашем тестере она выполнится по цене 184560, а в реальности она бы выполнилась по цене 184500.
Разница слишком существенна для быстрых и скальперских стратегий.

У всех трейдов лесенки время Trade.Time=23.00. Поэтому какой бы "интервал перегенерации стакана " я...

2011-02-24T14:07:12Z

pyhta4og

У всех трейдов лесенки время Trade.Time=23.00. Поэтому какой бы "интервал перегенерации стакана " я ни передавал в HistoryTestTrader в конструктор, генератор стакана МЕЖДУ этими трейдами вызываться не будет. Поэтому не будет сгенерировано стаканов по этим трейдам (которые и могли бы привести к матчингу заявки <1>)

По этим данным надо понять, исполнятся фиктивные лимитки или нет. Тут несколько случаев: Случай А. ...

2011-02-24T11:16:48Z

pyhta4og

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

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

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

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

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