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

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

У стакана пишется LastChangeTime

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

Точнее стаканы 23.40 и 24.35 (время стакана пишется над зеленым столбиком). Трейды лесенкой в реальности были между этими стаканами. Но из-за несинхронности получения стаканов и трейдов, стакан 24.35 пришел до трейдов.

Заявка <1> будем считать выставлена заранее, допустим в 19.00. Она останется висеть в эмуляторе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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: Там миллисекунды будут совершенно не те (даже секунды будут не те).

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

Juri:

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

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

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

Mikhail Sukhov:

Juri:

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

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

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

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

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

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

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

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

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

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