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

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


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

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

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



Спасибо:


<< < 2 3 4 5  >
pyhta4og

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


Цитата:

Ок, тогда я видимо не совсем Вас понял. Вернемся к картинке. По какому принципу голубым вверху проставляются цифры? Я думал это 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>)

Спасибо:

andy

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


pyhta4og

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

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

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

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


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

Mikhail Sukhov

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


pyhta4og

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


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

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

Juri

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


Mikhail Sukhov


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

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


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

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

pyhta4og

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


Цитата:

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

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

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

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

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

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

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

Цитата:

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


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

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

Mikhail Sukhov

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


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


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

Juri

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


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 часа )
Спасибо:

Mikhail Sukhov

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


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


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


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

pyhta4og

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


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


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


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


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

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

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

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

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


Спасибо:

Mikhail Sukhov

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


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


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

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

loading
clippy