getitem и тип сделки. маркет-мейкер маркет-тейкер

Страницы: 1
RSS
getitem и тип сделки. маркет-мейкер маркет-тейкер
 
Друзья, подскажите, если кто-нибудь знает:
Мне в скрипте при запросе типа getitem в таблице сделок deals необходимо для i- й сделке понять была ли она маркет-мейкерская или маркет-тейкерская для определения размера комиссии Мосбиржи для класса инструментов TQBR. Могу ошибаться, но комиссия ТС в этой таблице deals не учитывает активность/пассивность сделки(т. е. комиссия всегда отражается, не важно, были ли сделка заключена "по рынку" или "лимитная". В самой таблице deals в QUIK есть поле "Состояние", принимающее значение "А" и "П", но вот как его  запросить с помощью getitem, я не понимаю. Есть какой то битовый флаг? Помогите пожалуйста 🥺
 
что-то я не вижу таблицу deals в списке таблиц, используемых в функциях getItem (см док)

TableNameТаблица
firmsФирмы
classesКлассы
securitiesИнструменты
trade_accountsТорговые счета
client_codes* Коды клиентов
all_tradesОбезличенные сделки
account_positionsПозиции участника по деньгам
ordersЗаявки
futures_client_holdingПозиции по клиентским счетам  (фьючерсы)
futures_client_limits Ограничения по клиентским  счетам
money_limitsПозиции по деньгам
depo_limitsПозиции по инструментам
tradesСделки
stop_ordersСтоп-заявки
neg_dealsЗаявки на внебиржевые  сделки
neg_tradesСделки для исполнения
neg_deal_reportsОтчеты по сделкам для  исполнения
firm_holdingПозиции участника по инструментам  
account_balanceПозиции участника по торговым счетам  
ccp_holdingsОбязательства и требования по активам  
rm_holdingsВалюта: обязательства и требования по  активам

* - функция  getNumberOf("client_codes") возвращает количество доступных

==================================

Дайте ссылку, где в документации на QLUa Вы ее нашли.
 
Я перепутал, не deals, а trades имел в виду в getItem
 
Цитата
написал:
Я перепутал, не deals, а trades имел в виду в getItem
примерно так:
capacityNUMBERРоль в исполнении заявки. Возможные значения:  
  • «0» – не определено;
  • «1» – Agent;
  • «2» – Principal;
  • «3» – Riskless principal;
  • «4» – CFG give up;
  • «5» – Cross as agent;
  • «6» – Matched principal;
  • «7» – Proprietary;
  • «8» – Individual;
  • «9» – Agent for other member;
  • «10» – Mixed;
  • «11» – Market maker
Код
n = getNumberOf("trades")
   for i=0,n-1 do
      local t = getItem("trades", i)
                if t.capacity==11 then   
                -- это Market maker
                end
   end
 
Спасибо, я проверю на практике, но у меня закралось сомнение, что это не совсем тот маркет-мейкер, что нужно. Если не ошибаюсь тут маркет-мейкер - это не то, как была исполнена заявка(по рынку или как лимитная) , а как признак того, что заявка была выставлена участником маркет-мейкером.
Код
 
Нашел вот тут в описании flag самой таблицы trades, но нужно проверять(как доберусь до ПК)

Бит 6(0x40) - по нему можно попнять , что сделка была исполнена как лимитная, а не рыночная .

Может кто уже этим пользовался и подтвердит

Набор битовых флагов
ПараметрТипОписание
бит 0 (0x1)-Заявка активна, иначе – не активна
бит 1 (0x2)-Заявка снята. Если флаг не установлен и значение бита «0» равно «0», то заявка исполнена
бит 2 (0x4)-Заявка на продажу, иначе – на покупку. Данный флаг для сделок и сделок для исполнения определяет направление сделки (BUY/SELL)
бит 3 (0x8)-Заявка лимитированная, иначе – рыночная
бит 4 (0x10)-Разрешить / запретить сделки по разным ценам
бит 5 (0x20)-Исполнить заявку немедленно или снять (FILL OR KILL)
бит 6 (0x40)-Заявка маркет-мейкера. Для адресных заявок – заявка отправлена контрагенту
бит 7 (0x80)-Для адресных заявок – заявка получена от контрагента
бит 8 (0x100)-Снять остаток
бит 9 (0x200)-Айсберг-заявка
 
Цитата
написал:
Спасибо, я проверю на практике, но у меня закралось сомнение, что это не совсем тот маркет-мейкер, что нужно. Если не ошибаюсь тут маркет-мейкер - это не то, как была исполнена заявка(по рынку или как лимитная) , а как признак того, что заявка была выставлена участником маркет-мейкером.  
Код
    
Из Вашего вопроса и следовало, что Вы хотите  узнать участника.
Чтобы получить нужный Вам ответ , пишите правильно вопросы.  
 
А вопрос-то правильный, интересный и нужный. И хорошо бы узнать, что скажут об этом разработчики.
Поскольку внятного ответа так и не было, подниму тему вновь. Вопросов здесь, на самом деле, два:
1. Какой параметр в таблице сделок (или в данных, получаемых от прерывания OnTrade) позволяет определить, была ли сделка "тейкерной" или "мейкерной" в том смысле, что заложен в комиссионные тарифы Мосбиржи?
2. Зависит ли передача этого параметра в терминал пользователя от настроек на стороне брокера?
 
Цитата
Glukator написал:
А вопрос-то правильный, интересный и нужный. И хорошо бы узнать, что скажут об этом разработчики.
Поскольку внятного ответа так и не было, подниму тему вновь. Вопросов здесь, на самом деле, два:
1. Какой параметр в таблице сделок (или в данных, получаемых от прерывания OnTrade) позволяет определить, была ли сделка "тейкерной" или "мейкерной" в том смысле, что заложен в комиссионные тарифы Мосбиржи?
2. Зависит ли передача этого параметра в терминал пользователя от настроек на стороне брокера?
Нет там проблем никаких. Просто nshch спутал Сделки с Заявками и выкатил сюда описание битовых флагов для Заявок. В описании флагов для Сделок всё есть:
бит 5 (0x20) Пассивная сделка («Состояние» — «П»)
бит 6 (0x40) Активная сделка («Состояние» — «А»)
 
Игорь М, спасибо! Лишь бы оно работало. А то ж знаете сами, квик такая штуковина чудесатая. Есть-то много чего, только работает все это порой довольно странно и с кучей условностей :)  
 
Вопрос-то, может, и правильный, но мало интересный и совсем уж не нужный. Во-первых, очевидно, что Квик знает о том, была ли сделка тейкерной или мейкерной - достаточно посмотреть на цифирь комиссии в портфеле. Во-вторых, эти данные нафиг не нужны: при подаче заявке мы не можем гарантировать, будет ли сделка тейкерной или мейкерной, а после того, как сделка состоялась, это и тем более никому не интересно. В-третьих, что за бред? Как это
бит 5 (0x20) Пассивная сделка ("Состояние" - "П")
бит 6 (0x40) Активная сделка ("Состояние" - "А")

Если я что-нибудь в чём-нибудь понимаю, то сделка может быть либо активной либо пассивной, то есть это ОДИН бит информации, а здесь их ДВА. И что будем делать с состояниями 0x00 и 0x60?
 
Цитата
Владимир написал:
<...> Во-первых, очевидно, что Квик знает о том, была ли сделка тейкерной или мейкерной - достаточно посмотреть на цифирь комиссии в портфеле.<...>
А поподробнее? В каком портфеле? Имеете в виду значение exchange_comission в данных, приходящих в OnTrade()?
Цитата
Владимир написал:
<...> при подаче заявке мы не можем гарантировать, будет ли сделка тейкерной или мейкерной, а после того, как сделка состоялась, это и тем более никому не интересно.<...>
Так никто и не говорит о том, что надо что-то "гарантировать". Речь о том, чтобы надежно узнать, какой именно была состоявшаяся сделка, чтобы рассчитать размер комиссии - а когда еще это делать, если не по факту заключения сделки? Может, квик чего-то там и присылает в OnTrade() о комиссиях, но насколько можно этим данным доверять, вот вопрос. Я в курсе, что вы на комиссии болт кладете (или уже нет?), но мне лично спокойнее, когда учет денег ведется возможно точнее.
Цитата
Владимир написал:
В-третьих, что за бред? Как это
бит 5 (0x20) Пассивная сделка ("Состояние" - "П")
бит 6 (0x40) Активная сделка ("Состояние" - "А")

Если я что-нибудь в чём-нибудь понимаю, то сделка может быть либо активной либо пассивной, то есть это ОДИН бит информации, а здесь их ДВА. И что будем делать с состояниями 0x00 и 0x60?
Вот всю подобную хрень я и имею в виду, когда говорю, что квик - штука местами странная, а работает все это с кучей условностей. Сам стараюсь от квика брать только минимум самых необходимых данных. А то полезешь глубже - а там два бита вместо одного, или еще какое-нибудь говно кучерявое.  
 
Glukator, Таблица такая есть в Квике, "состояние счёта" называется. А там есть ячеечка "комиссия". Я просто вижу в ней, что при сделках там либо что-то тикает либо (как правило) стоит на месте. Она меня мало интересует, так что я даже не слышал, что есть такое "значение exchange_comission в OnTrade". Я никогда не обращал внимание ни на комиссии ни на дивиденды, считая, что одно приблизительно компенсирует другое. Это может быть интересно разве что для технологий торговли типа HFT, а мой скрипт торгует куда спокойнее: число сделок за сутки исчисляется десятками, реже сотнями, а в расчёте на один тикер редко приходятся даже десятки. У меня, в принципе, учитывается комиссия, но грубо, по максимуму, для всех совершённых сделок - не помню, кажется 0.1% или чуть меньше, но только для акций и только с той целью, чтобы скрипт не вычерпывал выделенный ему депозит досуха. И чуть доработал алгоритм, когда ввели эту утроенную комиссию, чтобы снизить вероятность тейкерских сделок - не помню, кажется только для фьючерсов.

Вот и я стараюсь от квика брать только минимум самых необходимых данных - ЭТИ данные мне не нужны.
 
Владимир, таблицу "состояние счета" я стараюсь не открывать. В целом она, конечно, хороша. Два только недостатка:
1. Эта сволочь неведомым образом в случайное время (особенно, почему-то, во время закрытия дневной сессии) начинает тормозить квик так, что в скрипте 1-секундный интервал sleep() в цикле main() растягивается на реальных 4 секунды и больше. Но это у меня. Возможно потому, что под биржевые игрушки выделен старый нетбук с 2 гигами памяти и каким-то там селероном о двух вёдрах.
2. Для решения задачи расчета комиссии на отдельные сделки совершенно бесполезна :)
 
Glukator,   Эта таблица у меня всегда открыта в одной из вкладок, я туда смотрю очень редко, но никаких тормозов сроду не замечал. У меня точно такой же ноут для торговли: 2 ядра, 2 гига ОЗУ, 2 ГГц, и sleep у меня на 0.25 секунды, 1000 тикеров спокойно держит. Видимо, потому, что я никакие комиссии на отдельные сделки вообще не считаю. :smile:  
 
Цитата
Владимир написал:
<...>2 ядра, 2 гига ОЗУ, 2 ГГц, и sleep у меня на 0.25 секунды, 1000 тикеров спокойно держит. Видимо, потому, что я никакие комиссии на отдельные сделки вообще не считаю.<...>
Конечно, поэтому. Не потому же, что алгоритмы хорошо продуманны  :smile:
А если серьезно, я из ваших идей многое для себя взял по части механики торговли. От использования единственного прерывания OnTrade() со стеками сделок и заявок с ограниченным временем жизни до распределения операций в цикле main() по прерываниям на 0.25/0.5/1.0/2.0 секунд для балансировки нагрузки на проц ввиду его дохлости. Осталось еще вот только сама малость - алгоритмы довести до уровня, чтоб на комиссии можно было плевать :))
 
Цитата
Владимир написал:

Если я что-нибудь в чём-нибудь понимаю, то сделка может быть либо активной либо пассивной, то есть это ОДИН бит информации, а здесь их ДВА. И что будем делать с состояниями 0x00 и 0x60?
0x00 - отмененное состояние.
0x60  - прикольно . Расскажите, как уместить 60 в два бита?  
 
nikolz,  Лапуль, Вы ХОТЬ ЧТО-НИБУДЬ в программ ировании соображаете? С какого там класса нынешние школьники начинают изучать информатику? Вот в тот самый класс и загляните - надеюсь, объяснят.
 
Цитата
Владимир написал: Во-вторых, эти данные нафиг не нужны: при подаче заявке мы не можем гарантировать, будет ли сделка тейкерной или мейкерной, а после того, как сделка состоялась, это и тем более никому не интересно.
Можем. Для этого всё и делалось. Мейкерная заявка с условием "Только пассивная" (скриптом или руками) поданная по рынку будет отклонена биржей. Обсуждали уже здесь.
 
Игорь М,  Я видел. Только этот "метод" не гарантирует, что сделка вообще состоится. Это СОВСЕМ УЖ идиотский способ. В любом случае для одной из сторон (как минимум) сделка будет активной, и если все применят столь  гениальное решение, торги прекратятся.
 
Цитата
Владимир написал:
nikolz,  Лапуль, Вы ХОТЬ ЧТО-НИБУДЬ в программ ировании соображаете? С какого там класса нынешние школьники начинают изучать информатику? Вот в тот самый класс и загляните - надеюсь, объяснят.
Может просто признаете , что написали хрень.
----------------------------
Ах, да, Вы же самый крутой петух в этой курятне.  
 
nikolz,   Лапуль, по сравнению с Вами самая последняя курица будет выглядеть самым крутым петухом. Ладно, в качестве ликбеза: 60 и 0x60 - это РАЗНЫЕ числа. А для особо одарённых здесь открытым текстом писали про пятый и шестой бит. И уж персонально для Вас: пятый и шестой - это ДВА бита.
 
Как всегда, хороший вопрос перевели в срач.
В продолжение темы: насколько реально когда-нибудь объем свечи ds:V(n) получать в виде V(n).maker+V(n).taker?
 
Цитата
Kolossi написал:
Как всегда, хороший вопрос перевели в срач.
В продолжение темы: насколько реально когда-нибудь объем свечи ds:V(n) получать в виде V(n).maker+V(n).taker?
Так это и 10 лет назад можно было, ещё на Qpile такое писали. Пишете скрипт, который ТОС обрабатывает, и выводите результат в таблицу или метками на график.
 
Цитата
Игорь М написал:
Цитата
Kolossi написал:
Как всегда, хороший вопрос перевели в срач.
В продолжение темы: насколько реально когда-нибудь объем свечи ds:V(n) получать в виде V(n).maker+V(n).taker?
Так это и 10 лет назад можно было, ещё на Qpile такое писали. Пишете скрипт, который ТОС обрабатывает, и выводите результат в таблицу или метками на график.
И как я не догадался :).  Только вот как-то не хочется держать открытыми тиковые базы по всем нужным тикерам и шуршать фильтрами когда мне нужны такие данные по часовым свечам. На сервере брокера при подготовки свечной базы по любому периоду это сделать гораздо проще и логичнее.
 
Возвращаясь к вопросу, поставленному в теме.
Неделю назад отправил свой скрипт в свободное плавание вот с такой конструкцией в OnTrade():
Код
function OnTrade(trade)
    <...>
    is_maker = bit.test(trade.flags, 5) and not bit.test(trade.flags, 6)
    <...>
end
Если is_maker == false, то считаем, что сделка прошла по рынку.
Последующее сопоставление логов скрипта с отчетом брокера о сделках не выявило расхождений между ними в вопросе разделения сделок на мейкерные и тейкерные.

В целом, значит, можно утверждать, что хотя бы у одного брокера (ВТБ), хотя бы на одной версии квика (10.3.1.13) эта конструкция работоспособна.
Страницы: 1
Читают тему
Наверх