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


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

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

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



Спасибо:




48 Ответов
1 2  >
Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 17.02.2011
Ответить


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


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

andy Перейти

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


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

andy Перейти

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


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

andy

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


Mikhail Sukhov Перейти

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

Да правильно - по цене не хуже.

Возможно я неточно сформулировал. Рассмотрим на примере.
Пусть у нас есть точные исторические данные по тикам и стаканам. Мы создаем лимитированную заявку на покупку с минимальным объемом и ценой 100. Ордер попадает на биржу.
1) Если в этот момент в стакане ask <= 100, то ордер будет исполнен по цене ask (например, 90)?
2) Если ask > 100, то ордер попадает в стакан, правильно?
3) После того, как ордер оказывается в стакане он может выполниться только по своей цене (100)?
4) При каком условии он выполниться: когда приходят сделки по цене <= 100 или когда цена ask из стакана <= 100?
Автор топика
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 18.02.2011
Ответить


andy Перейти
Mikhail Sukhov Перейти

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

Да правильно - по цене не хуже.

Возможно я неточно сформулировал. Рассмотрим на примере.
Пусть у нас есть точные исторические данные по тикам и стаканам. Мы создаем лимитированную заявку на покупку с минимальным объемом и ценой 100. Ордер попадает на биржу.
1) Если в этот момент в стакане ask <= 100, то ордер будет исполнен по цене ask (например, 90)?
2) Если ask > 100, то ордер попадает в стакан, правильно?
3) После того, как ордер оказывается в стакане он может выполниться только по своей цене (100)?
4) При каком условии он выполниться: когда приходят сделки по цене <= 100 или когда цена ask из стакана <= 100?


1. Да.
2. Выражение не понятно.
3. Вы же в пункте 1 писали об обратном... Ордер будет выполняться по лучшем оферам до тех пор, пока не закончится баланс или цена офера не превысит 100.
4. Все заявки матчаться на основе стакана.

Вы лучше скажите, в чем собственно вопрос.
Спасибо:

andy

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


Цитата:
Вы лучше скажите, в чем собственно вопрос.

Вопрос был в том по какому алгоритму матчатся лимитированные заявки.

Попробую объяснить почему, как мне кажется, текущий алгоритм не учитывает все варианты выполнения ордера.
Пусть изначально стакан на тестовой бирже выглядит так
Ask 110 1
Bid 90 1
Bid 80 1

После установки ордера
Ask 110 1
Bid 100 1 * наша заявка
Bid 90 1
Bid 80 1

После этого скажем кто-то продает по рынку, тогда в исторических тиковых данных мы увидим сделку по 90. При этом хотя цена ask не меняется, наш ордер должен выполниться по 100.
Ask 110 1
Bid 80 1
Автор топика
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 18.02.2011
Ответить


Заявки исполняются по стакану, а не по тикам. Поэтому, историческая сделка не влияет на исполнение заявок.
Спасибо:

Juri

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


Mikhail Sukhov Перейти
Заявки исполняются по стакану, а не по тикам. Поэтому, историческая сделка не влияет на исполнение заявок.


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

Сможет Ваш тестер моделировать такую стратегию?
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 18.02.2011
Ответить


Juri Перейти
Mikhail Sukhov Перейти
Заявки исполняются по стакану, а не по тикам. Поэтому, историческая сделка не влияет на исполнение заявок.


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



Не понял, как одно следует из другого.
Спасибо:

Juri

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


Mikhail Sukhov Перейти
Juri Перейти
Mikhail Sukhov Перейти
Заявки исполняются по стакану, а не по тикам. Поэтому, историческая сделка не влияет на исполнение заявок.


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



Не понял, как одно следует из другого.



В одном из предыдущих постов был пример

Пусть изначально стакан на тестовой бирже выглядит так
Ask 110 1
Bid 90 1
Bid 80 1

После установки ордера
Ask 110 1
Bid 100 1 * наша заявка
Bid 90 1
Bid 80 1

После этого скажем кто-то продает по рынку, тогда в исторических тиковых данных мы увидим сделку по 90. При этом хотя цена ask не меняется, наш ордер должен выполниться по 100.
Ask 110 1
Bid 80 1


Как я понял из вашего ответа в этом примере "наша заявка" не будет исполнена в Вашем эмуляторе.
Так?

Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 18.02.2011
Ответить


Juri Перейти

Как я понял из вашего ответа в этом примере "наша заявка" не будет исполнена в Вашем эмуляторе.
Так?



Давайте я еще раз пропишу схему. Матчинг идет по стакану, не по сделкам. Если есть стакан в истории, по нему идет сопоставление удовлетвориться заявка или нет. Если стакана нет, то он генерируется рандомно по последней сделки. И далее точно так же как и с сохраненным стаканом. Тоесть, то что есть исторический тик на 90р, не играет существенной роли.
Спасибо:

andy

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


Mikhail Sukhov Перейти
Заявки исполняются по стакану, а не по тикам. Поэтому, историческая сделка не влияет на исполнение заявок.


Я понял. Есть ли какая то возможность изменить алгоритм матчинга - через реализацию интерфейса или как-то еще?
Автор топика
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 20.02.2011
Ответить


andy Перейти
Mikhail Sukhov Перейти
Заявки исполняются по стакану, а не по тикам. Поэтому, историческая сделка не влияет на исполнение заявок.


Я понял. Есть ли какая то возможность изменить алгоритм матчинга - через реализацию интерфейса или как-то еще?


Нет, нельзя. Механизм матчинга един на все времена и биржи, зачем его менять.

Мне кажется, вам нужно не сам механизм матчинга менять, а генерации стакана - HistoryTestTrader.MarketDepthGenerator.
Спасибо:

Juri

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


Mikhail Sukhov Перейти
andy Перейти
Mikhail Sukhov Перейти
Заявки исполняются по стакану, а не по тикам. Поэтому, историческая сделка не влияет на исполнение заявок.


Я понял. Есть ли какая то возможность изменить алгоритм матчинга - через реализацию интерфейса или как-то еще?


Нет, нельзя. Механизм матчинга един на все времена и биржи, зачем его менять.

Мне кажется, вам нужно не сам механизм матчинга менять, а генерации стакана - HistoryTestTrader.MarketDepthGenerator.


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

Может быть, я что-то неправильно понял, но из того, что здесь сказано выходит, что Ваш метод матчинга не совсем соответствует действительности.
Зачем генерировать стакан, если он у нас есть реальный.
К сожалению, опять придется писать тестирование стратегий самому (
Это тем более обидно, что Ваш проект представляется мне весьма интересным и перспективным.
Было желание взять его за основу в своей работе, а при таком раскладе - не знаю...
Хотя может быть Вы передумаете и переделаете алгоритм матчинга на более адекватный?
Наверно, какое-то время послежу за Вашим проектом в надежде на это.

С Уважением, Юрий.
Спасибо:

andy

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


Mikhail Sukhov Перейти
andy Перейти


Я понял. Есть ли какая то возможность изменить алгоритм матчинга - через реализацию интерфейса или как-то еще?


Нет, нельзя. Механизм матчинга един на все времена и биржи, зачем его менять.

Мне кажется, вам нужно не сам механизм матчинга менять, а генерации стакана - HistoryTestTrader.MarketDepthGenerator.


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

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

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 20.02.2011
Ответить


Juri Перейти

Может быть, я что-то неправильно понял, но из того, что здесь сказано выходит, что Ваш метод матчинга не совсем соответствует действительности.
Зачем генерировать стакан, если он у нас есть реальный.
К сожалению, опять придется писать тестирование стратегий самому (
Это тем более обидно, что Ваш проект представляется мне весьма интересным и перспективным.
Было желание взять его за основу в своей работе, а при таком раскладе - не знаю...
Хотя может быть Вы передумаете и переделаете алгоритм матчинга на более адекватный?
Наверно, какое-то время послежу за Вашим проектом в надежде на это.


1. Ни какого шантажа, я это не люблю.
2. Каждый выбирает что ему лучше. Если Вы оценили, что проще сделать все самому, то надо делать самому, имхо.
3. Если хотите чтобы были произведены переделки, то надо мысль донести свою правильно. Я пока даже не понял, с чем Вы не согласны и что Вы хотите переделать. Я всегда делаю изменения, если они логичны. В данном случае, я пока и логичность оценить не могу.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 20.02.2011
Ответить


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

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


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

Juri

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


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


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

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 21.02.2011
Ответить


Juri Перейти
Зачем генерировать стакан, если он у нас есть реальный.


У вас сохранена история по стаканам?
Спасибо:

Juri

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


Mikhail Sukhov Перейти
Juri Перейти
Зачем генерировать стакан, если он у нас есть реальный.


У вас сохранена история по стаканам?


Есть и сохраненная, а можно и в будущем насохронять сколько нужно.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 21.02.2011
Ответить


Juri Перейти
Mikhail Sukhov Перейти
Juri Перейти
Зачем генерировать стакан, если он у нас есть реальный.


У вас сохранена история по стаканам?


Есть и сохраненная, а можно и в будущем насохронять сколько нужно.


Это важный момент. То что вы описывали выше происходит при сохраненном стакане или без стакановой истории?
Спасибо:

Juri

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


Mikhail Sukhov Перейти
Juri Перейти
Mikhail Sukhov Перейти
Juri Перейти
Зачем генерировать стакан, если он у нас есть реальный.


У вас сохранена история по стаканам?


Есть и сохраненная, а можно и в будущем насохронять сколько нужно.


Это важный момент. То что вы описывали выше происходит при сохраненном стакане или без стакановой истории?


Это происходит в реальности. Ну если в модельных терминах, то наверно, при сохраненном стакане.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 21.02.2011
Ответить


Juri Перейти
Это происходит в реальности. Ну если в модельных терминах, то наверно, при сохраненном стакане.


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

andy

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


Mikhail Sukhov Перейти

Ок, мне кажется идет банальное непонимание друг друга в плане терминологии. Что такое матчинг? Это процесс сопоставления заявки со стаканом.


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

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

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

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 21.02.2011
Ответить


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


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

andy Перейти

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


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

1. При загруженном стакане тиковая сделка вообще слабо влияет на ситуацию, так как стакан является более точными данными, и если сделка тиковая ему противоречит, то скорее всего проблема в сделке, а не в стакане. Например, это может быть из-за того, что точность сделок секундная, в то время как стакан оперирует миллисекундами. Верить сделке не стоит, поэтому ее просто отбрасываем из нашего уравнения. И так, у нас осталась только наша заявка на покупку по 100 + загруженный стакан с лучшим бидом в 90 и офером в 110. Заявка выполнена не будет, что вполне логично, так как текущая ситуация на рынке не способствует покупке по 100.

2. Стакан был сгенерирован на основе тиковой сделки в 90. Отправной точкой будет цена в 90. Стакан будет сгенерирован с лучшим бидом в 90 - random и лучшим офером 90 + random (в версии 3.0.6 по другому, но на данную ситуацию это не влияет). Скорее всего, если шаг цены равен 1, заявка исполниться.

Вопрос, что не так в этих двух ситуациях и как бы Вы это изменили?
Спасибо:

Juri

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


Mikhail Sukhov Перейти

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?

Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 22.02.2011
Ответить


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


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

Juri Перейти

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


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

Juri Перейти

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


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

Juri Перейти

А вот получить стакан с милисекудной точностью мне не удалось. QUIK выдает стакан как раз 1 раз в сек.


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

Juri Перейти

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


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

Juri Перейти

Тогда такой вопрос. По какой цене будет исполнена Рыночная заявка на покупку, если реальный Ask=110, а сгенерированный например равен 99?


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

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

loading
clippy