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


Попробовал выставлять лимитированные заявки: правильно ли я понял, что они выполнятся при условии, если цена 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