Отцы, с праздниками! Посоветуйте, пожалуйста, есть ли возможность в квике возможность связать сделку с позицией, а именно узнать время образования позиции? Т.е. у меня задача закрыть позицию не позднее 3 свечей от свечи, когда прошла сделка. Можно ли в квике как-то понять, что имеющаяся позиция возникла тогда-то и во столько?
Acaw написал: Отцы, с праздниками! Посоветуйте, пожалуйста, есть ли возможность в квике возможность связать сделку с позицией, а именно узнать время образования позиции? Т.е. у меня задача закрыть позицию не позднее 3 свечей от свечи, когда прошла сделка. Можно ли в квике как-то понять, что имеющаяся позиция возникла тогда-то и во столько?
Есть таблица сделок и там время сделки. Есть библиотека QLUA и там функции для чтения параметров сделки т е времени этой сделки.
Спасибо за ответы, отец! разбираюсь с обработкой коллбэков по заявкам, onTransReply, onOrder, onTrade. При этом есть коллбэки на изменение позиций по деньгам и инструментам. Т.е. если у нас выставилась заявка значит изменилась позиция по деньгам, т.к. заблокировался объем, если прошла сделка, значит изменилась позиция по депо. А что если использовать эти коллбэки и смотреть в соответствующие таблицы для подбития баланса. В моих целях отслеживание коллбэков по заявкам нужно для понимания именно позиций по деньгам и инструментам, чтобы например не накупить лишнего, не превысить лимиты робота, не попасть на маржинальную позицию. Что думаете и как обстоят дела в реальности с этими коллбэками?
Acaw написал: Спасибо за ответы, отец! разбираюсь с обработкой коллбэков по заявкам, onTransReply, onOrder, onTrade. При этом есть коллбэки на изменение позиций по деньгам и инструментам. Т.е. если у нас выставилась заявка значит изменилась позиция по деньгам, т.к. заблокировался объем, если прошла сделка, значит изменилась позиция по депо. А что если использовать эти коллбэки и смотреть в соответствующие таблицы для подбития баланса. В моих целях отслеживание коллбэков по заявкам нужно для понимания именно позиций по деньгам и инструментам, чтобы например не накупить лишнего, не превысить лимиты робота, не попасть на маржинальную позицию. Что думаете и как обстоят дела в реальности с этими коллбэками?
Все верно. Но при старте или каждом новом соединении надо просматривать соответствующие таблицы. -------------------------- Можно и без этих колбеков. Если зарегистрировали новую активную заявку, то изменится баланс по деньгам. Если зарегистрировали исполнение заявки, то изменится баланс по деньгам и бумагам. Таким образом, достаточно коблека заявок и таблиц money_limits и depo_limits для акций или аналогичные таблицы для фьючерсов и опционов.
В реальности лучше перед подачей транзакции пойти и посмотреть, что в соответствующих таблицах, рассчитать лимиты и параметры. Проблема в том, что колбек в терминале - весьма ненадёжная вещь. Точнее в спокойные периоды работает как ожидается и может создаться ощущение, что так будет всегда. Но бывают моменты, когда клиент-серверное взаимодействие настолько медленное - повышенная торговая активность, или просто сбой в работе сервера брокера, что эти колбеки не приходят, приходят повторно.
Так что я лучше проверю руками в самом источнике информации. Тем более, что этот контур всё равно необходимо реализовывать, например, при перезапуске скрипта. Колбеки прошли давно, а понять ситуацию необходимо сейчас.
Позицию же необходимо вести самостоятельно. Да, бывают ситуации когда сделка прошла вне работы скрипта и необходимо провести выравнивание. Но в целом, прошла сделка - запомнил. Запустил скрипт - просканировал сделки и убедился, что запомненная позиция корректна с точки зрения количества. Где запоминать - это выбор по предпочтениям. То ли в файле состояния, то ли в базе данных. Не важно. Лог файл не предназначен для хранения информации, это инструмент анализа.
"Запустил скрипт - просканировал сделки и убедился, что запомненная позиция корректна с точки зрения количества. " Если у нас эталон это источник данных, то тогда зачем нужны коллбеки, когда всегда можно посмотреть в таблицу сделок и снять состояние. Тем более, если мы доверяем источнику, то если запомненная позиция отличается, то что, мы ее приводим в соответствие источнику? Тогда зачем запоминать. На поверхности разница только в том, что колбеки в идеале приходят по факту изменения позиции, а смотреть нужно руками в какое-то время, как минимум перед действием (входом/выходом из позиции) при завершении работы скрипта в конце дня, чтобы зафиксировать сделки и обновить позицию. Но опять таки вопрос, зачем нагружать скрипт дерганием по коллбекам? Допустим отправку транзакции нужно фиксировать, а onTransReply обрабатывать, если вдруг ошибка. А результаты onOrder и OnTrade по идее должны отражаться в таблицах, может чуть чуть позже, но не суть. Так все же какой сакраментальный смысл в их обработке?
onTransReply тоже можно в источнике посмотреть, но тут кажется дешевле коллбек обработать. Можно и с заявками и сделками тоже дешевле? Ведь по итогу дня может быть и 1000 заявок и сделок и каждый раз дергать таблицу это замедление работы? Но опять таки если все равно с таблицей нужно сверяться, не очень понятна логика.
Логика проста. Колбек - это реакция на событие, в терминале - это изменение соответствующей таблицы. Например, установили ордер - появилась запись в таблице ордеров. Ордер исполнился - изменился статус (флаг состояния). Всё, вроде, красиво. Обработай колбек - получили результат. Минимум усилий, скрипт почти всё время работает в холостую, ожидая колбеки.
Но, как говорил выше, реальность же сложнее. Скрипт может быть остановлен, а ордер исполнился в это время. Пользователь решил руками закрыть или открыть позицию - а почему нет, спрашивается. Сдвинул ордер на графике и т.д. Да и просто может выключить терминал вечером, когда ещё идет вечерняя сессия. Не у всех терминал на постоянно работающем VPS.
Т.е. есть разные ситуации. Если Вы пишите скрипт для себя и прекрасно понимаете что можно, а что нельзя делать, то да, используйте колбеки, понимаю их риски. Плюс учитывая, что они приходят не один раз на одно событие. А вот если скрипт не для себя, то уже приходится писать с расчётом на то, что будет выполнено всё то, что Вы не предполагаете. Могут даже пожаловаться на то, что сделка не открылась после выключения терминала. Я же скрипт запустил, выключил терминал чтобы не сидеть перед ним - где сделка?
Да, но я спрашивал несколько другой аспект. Что лучше обрабатывать для ведения позиции коллбеки или таблицы, учитывая ненадежность коллбеков? Если и то и то, то нужно это все постоянно приводить к одному, а если исходить, что первоисточник это таблица и сверяемся с ней, то зачем обрабатывать коллбек. Разве что коллбек может придти раньше обновления таблицы, но эта нано разница не играет роли.
Acaw написал: Да, но я спрашивал несколько другой аспект. Что лучше обрабатывать для ведения позиции коллбеки или таблицы, учитывая ненадежность коллбеков? Если и то и то, то нужно это все постоянно приводить к одному, а если исходить, что первоисточник это таблица и сверяемся с ней, то зачем обрабатывать коллбек. Разве что коллбек может придти раньше обновления таблицы, но эта нано разница не играет роли.
Я предпочитаю таблицы. Кто-то колбеки. Причина выше - всё равно необходимой пройтись по сделкам, ордерам, чтобы проверить что случилось с момента прошлого запуска скрипта. Да и надёжней это. Хоть и кто-то скажет - как можно, это же "прошлый век". Но в том-то и дело, что если задача надёжно получить информацию, то необходимо в реальном времени постоянно опрашивать датчик. Так и здесь. Мы же про деньги говорим и алгоритмы в реальном времени работают.
Acaw написал: Да, но я спрашивал несколько другой аспект. Что лучше обрабатывать для ведения позиции коллбеки или таблицы, учитывая ненадежность коллбеков? Если и то и то, то нужно это все постоянно приводить к одному, а если исходить, что первоисточник это таблица и сверяемся с ней, то зачем обрабатывать коллбек. Разве что коллбек может придти раньше обновления таблицы, но эта нано разница не играет роли.
Про колбеки Они надежны так же как таблицы. Так как они вызываются перед записью в таблицы. ----------------------- Проблема обычно бывает в том, что по рекомендации разработчиков в main используют sleep. Кроме того, начинающие писатели роботов не используют очередь событий. ---------------------------- Поэтому без очереди и c долгим sleep колбеки просто игнорируются main и не обрабатываются. ----------------------- Поэтому и возникают пропуски событий и не совпадает значение в таблице и по колбекам. --------------------- Если Вы не занимаетесь скальпингом то по таблицам работать проще --------------------- Но если колбеки не используете, То можно писать робота в индикаторе - это еще проще и также надежно. Выбор за вами
nikolz, Nikolay спасибо отцы! Буду грызть. Но как же не использовать sleep в main? Разве тогда квик не зависнет от постоянных действий? Какой sleep можно считать долгм? 200-300 не долгий? Т.е. если коллбек приходит во время sleep, то он может быть проигнорирован main и то, что должно быть сделано в этом коллбеке сделано не будет?
И еще простейший вопрос, который сложно проверить на практике. Если заявка исполняется частями, то у каждой сделки по этой заявке будет свой trade_num?
Что касается таблиц, то с одной стороны проще, но с другой надо запоминать какие сделки уже учтены в позиции, какие новые, хоть это и не сложно сделать. Допустим скрипт остановился и нужно восстановить позиции. У меня в файле записаны позиции, потом я их обновляю через разбор таблицы сделок. Но если в течении дня потребуется несколько раз их восстановить, то без отдельной записи сделок дня невозможно будет понять, какие из них уже учтены в позиции, а какие нет.
sleep обычно небольшой от 10 до 60 млс. Зачем 200 сразу. Сделки надо учитывать, да. Но их можно очищать уже через день. Даже на след. день, исключая те, что в вечернюю сессию на срочном рынке. Их и с колбеками необходимо учитывать, т.к. колбек может и приходит несколько раз на одно событие. А значит чтобы исключить повторный учёт, необходимо их запомнить. Особой проблемы в этом нет.
Цитата
каждой сделки по этой заявке будет свой trade_num
Да, будет. По одному ордеру может быть неограниченное число сделок, если представить такой ордер.
Acaw написал: nikolz , Nikolay спасибо отцы! Буду грызть. Но как же не использовать sleep в main? Разве тогда квик не зависнет от постоянных действий? Какой sleep можно считать долгм? 200-300 не долгий? Т.е. если коллбек приходит во время sleep, то он может быть проигнорирован main и то, что должно быть сделано в этом коллбеке сделано не будет?
И еще простейший вопрос, который сложно проверить на практике. Если заявка исполняется частями, то у каждой сделки по этой заявке будет свой trade_num?
Что касается таблиц, то с одной стороны проще, но с другой надо запоминать какие сделки уже учтены в позиции, какие новые, хоть это и не сложно сделать. Допустим скрипт остановился и нужно восстановить позиции. У меня в файле записаны позиции, потом я их обновляю через разбор таблицы сделок. Но если в течении дня потребуется несколько раз их восстановить, то без отдельной записи сделок дня невозможно будет понять, какие из них уже учтены в позиции, а какие нет.
Если освоите Си, то можно использовать функции Event и Wait (я их использую) и очередь и еще пул потоков. На форуме уже рассказывал. В этом случае время реакции main на колбек составляет не более 0.1 ms. ------------------------------------------- Если используете sleep, то меньше 10 ms не получится. Работает нормально. Но без очереди Вы обязательно пропустите кучу колбеков, так как они приходят пакетами т е практически одновременно деcятками. ------------------------------ По номеру сделки - это же номер сделки, а не заявки. Каждая сделка - это договор и у него уникальный номер. ------------------------------ Если делаете по таблицам,то надо запоминать что уже обрабатывали. Тогда все будет быстро. Например, в тесте у меня размер таблицы заявок составил 200 тысяч. Если делать просты перебором то ждать придется до завтра. -----------------------------. Я не пишу ничего в файлы, кроме параметров настройки и логов. Не вижу смысла это делать. Прошлое не исправишь и оно еще никого ничему не научило. --------------------- Если требуется сохранить в файлах, то можно выгрузить все в конце дня. Но пока у меня такой надобности не было.
А есть где почитать и главное увидеть элементарный пример постановки коллбека в очередь, в интернете именно такого примера не нашел. Могу только предположить, что в коллбеке поступившие данные пишутся в массив, который обрабатывается в main.
Куда же сохранять информацию о сделках, заявках, если не в файл. В терминале ее на следующий день нет, а мне важно понимать когда именно возникла позиция, от этой задачи все и пошло. Могу предположить, что в какую-нибудь базу данных, но это же тоже файл.
Можно ли обойтись перебором таблиц если предположить, что в реальной ситуации более 1000 сделок в день не будет.
И самое главное по поводу таблиц, запоминания и скорости. Пока я делаю так - в текстовый файл пишу номера ордеров сделок, затем когда перебираю таблицу сделок беру в рассмотрение те номера, которых нет в файле, но таблица сделок перебирается вся.
Всем добрый день, хочу просто добавить фундамент, в о сознание цели. Знание сила!
Коллбеки (или обратные вызовы) — это механизм, при котором одна функция передается как параметр в другую функцию, и она вызывается (или "вызвана") внутри этой функции, когда наступает определенное событие или условие. В контексте торгового алгоритма и работы с терминалом QUIK, коллбеки используются для получения данных (например, сделок) и их обработки в реальном времени. В очередь ставятся данные полученные от них, для уменьшения нагрузки.
Кто выступает контрагентом в сделке, и что нужно учитывать в скальпинге и подобных стратегиях.
1) Рынки МосБиржи, если рассматриваете ее, управляются маркет-мейкерами. Основные алгоритмы для обеспечения максимальной эффективности которые, можно даже сказать, обязан использовать маркет-мейкер: a) Алгоритмы выставления двустороних котировок; b) Алгоритмы управления позицией; c) Арбитражные алгоритмы; d) Алгоритмы управления рисками; e) Алгоритмы HFT (High-Frequency Trading). Работают не со стаканом а с книгой ордеров. Принцип работы HFT-алгоритмов (High-Frequency Trading): Осуществляют тысячи сделок в секунду. Мониторят микро изменения цен и мгновенно реагируют на рыночные дисбалансы. Технически: Используются FPGA (платы программируемой логики) для минимизации задержек. Торговля осуществляется максимально близко к серверам биржи (co-location), используются прямые подключения к биржевым серверам через высокоскоростные сети. Современные алгоритмы маркет-мейкеров работают с задержкой менее 1 миллисекунды. А в кризисных ситуациях может выйти из рынка.
2) На российском рынке сейчас преобладают частные инвесторы (МосБиржа), и этому есть простые объяснения. Вот из оценки брокера, доля частных инвесторов в объеме торгов акциями на ноябрь 2024г. - 76% за 2023г. -40%.
Разрабатывая архитектуру своей алгоритмической торговой программы, на мой взгляд, это нужно учитывать, особенно если стратегии скальперские. Луа в рамках QUIK, прекрасно справляется с торговыми задачами. Корутинный подход (асинхронность) прекрасно решает задачу Event и Wait озвученные nikolz, для этого, один из подходов создается своя таблица событий (Event).
Да, использую в обработке собственных сделок комбинированный подход. Ну про это говорили. Вот коллбек которым пользуюсь, на форуме он широко обсуждался, сто лет пользуюсь не заглядывая.
Код
--[[ Trade CALLBACK ]]-- -- Вызов колбэка OnTrade, который использует self для контроля и записи данных
--function OnTrade(trade) tradeManager:OnTrade(trade) end
function OnTrade(trade)
local key = trade.trans_id
local i=tonumber(sdelka[0]);
if working
and key and key>0
and (i==0 and key~=sdelka.id) or (i>0 and sdelka[i][1]~=key)
--and trade.sec_code==symbol --and trade.class_code==class
then
i=i+1;
sdelka[0]=i;
sdelka[i]={};
sdelka[i][0]=sdelka[0];
sdelka[i][1]=trade.trans_id;
sdelka[i][2]=get_date(trade.datetime)
sdelka[i][3]=get_time(trade.datetime)
sdelka[i][4]="B"; if bit.band(trade.flags,4)~=0 then sdelka[i][4]="S"; end;
local dir = sdelka[i][4]=="B" and 1 or sdelka[i][4]=="S" and -1 or 0;
sdelka[i][5]=trade.qty*dir;
sdelka[i][6]=trade.price;
----- comission
sdelka[i][7]=trade.clearing_comission+trade.exchange_comission+trade.tech_center_comission;
sdelka[i][8]=trade.order_num;
sdelka[i][9]=trade.trade_num;
sdelka[i][10]=trade.sec_code;
sdelka.id=trade.trans_id;
Log:info("OnTrade! sdelka "..i .."; "
.."; trans_id="..sdelka[i][1]
.."; "..sdelka[i][2]
.."; "..sdelka[i][3]
.."; "..sdelka[i][4]
.."; "..sdelka[i][5]
.."; "..sdelka[i][6]
.."; comission="..sdelka[i][7]
.."; onum="..sdelka[i][8]
.."; tnum="..sdelka[i][9]
.."; "..sdelka[i][10]
.."\n"
);
--local a,v; for a,v in pairs(sdelka[i) do Log:trace( 'OnTrade! sdelka['..i..']['..tostring(a)..'] = '.. tostring(v) ) end;
end
end;
О мифах про маркет мейкеров (MM). ------------------ MM это любой проф участник рынка, с который заключил с биржей договор об оказании услуг ММ. Задача MM - создание ликвидности, что фактически сводится к обеспечению минимального спреда. Условия такого договора есть на бирже. -------------------------------- Кратко, условие следующее. Если сделка стукает в позицию ММ, то биржа платит ему за такую сделку. Вот и все "тайны" ММ. Остальное - "теория заговора" -------------- После ухода многих иностранных игроков, биржа изменила правила на фьючерсах. В итоге на фьючерсах все , кто ставит пассивную заявку выполняют фактически задачу ММ. -------------------- В итоге на рынке стало меньше сделок по рыночной цене мелких игроков. А на рынке их уже 70%. В итоге меньше шума от толпы .
Acaw написал: А есть где почитать и главное увидеть элементарный пример постановки коллбека в очередь, в интернете именно такого примера не нашел. Могу только предположить, что в коллбеке поступившие данные пишутся в массив, который обрабатывается в main.
Куда же сохранять информацию о сделках, заявках, если не в файл. В терминале ее на следующий день нет, а мне важно понимать когда именно возникла позиция, от этой задачи все и пошло. Могу предположить, что в какую-нибудь базу данных, но это же тоже файл.
Можно ли обойтись перебором таблиц если предположить, что в реальной ситуации более 1000 сделок в день не будет.
И самое главное по поводу таблиц, запоминания и скорости. Пока я делаю так - в текстовый файл пишу номера ордеров сделок, затем когда перебираю таблицу сделок беру в рассмотрение те номера, которых нет в файле, но таблица сделок перебирается вся.
Я писал на форуме элементарные колбеки, которые использую сам. Использую лишь те колбеки, которые необходимы для данной задачи.
примеры:
Код
function OnClose() fconnect=nil end
function OnConnected(flag) fconnect=1; end
function OnDisconnected() fconnect=1 end
function OnStop(flag) fconnect=nil;return 2000 end
Код
function OnTransReply(t)
local stat=t.status; if stat<2 or stat==3 or sta==15 then return; end
local c,s=t.class_code,t.sec_code;
if c~=c_old or s_old~=s then tc=Tclas[c] if tc then ts=tc[s] end end
if ts then -
local id=t.trans_id;
local tt=ts[1]; del_trans(tt,id,M);
tt=ts[2]; del_trans(tt,id,M);
end
end
Код
function OnTrade(t)
local c,s=t.class_code,t.sec_code; if c~=clas or sec~=s then tc=Tclas[c] if tc then ts=tc[s] end end
if ts then tpr[Ntp]={Trade,t,tc,ts} EvSet(event); end
end
Код
function OnOrder(t)
local c,s=t.class_code,t.sec_code;
if c~=c_old or S~=s_old then tc=Tclas[c] if tc then ts=tc[s] end end
if ts then
local tt=ts[1]; local num=t.order_num; local id=t.trans_id;
local M=tt[0]; if M<0 then M=-M; end
local i=0 while M>i do i=i+1; if tt[i]==id then break; end i=i+1 end
if t.flags&1==1 then if M==i then Nor=Nor+1; tt[i]=Nor; end
else tt[i]=nil; end
Ntp=Ntp+1; tpr[Ntp]={Order,t,tc,ts} EvSet(event);
end
end
Код
function OnQuote(c,s)
if c~=c_old or S~=s_old then tc=Tclas[c] if tc then ts=tc[s] end end
if ts then local t={c,s}; Ntp=Ntp+1; tpr[Ntp]={Quote,t,tc,ts}
if 3>Ntp then EvSet(event); end
end
end
Вообще колбеки все могут быть одинаковые. Алгоритм такой: Получаемые в колбеке параметры упаковываем в таблицу с ключом и помещаем в очередь. вот пример:
Код
function OnTrade(t) tpr[#tpr+1]={"trade",t} EvSet(event); end
function OnOrder(t) tpr[#tpr+1]={"order",t} EvSet(event);end
function OnAllTrade(t) tpr[#tpr+1]={"AllTrade",t} EvSet(event);end
EvSet(event) - это функция установки события. Если используете sleep, то эту функцию убираете.
В main извлекаем из очереди и по ключу вызываем функцию для обработки параметров Вот и весь алгоритм. Хороший пример main и очереди есть в документации. Но очевидно мало кто читает документацию.
nikolz, На форуме существует некая путаница в понятиях, и Вы не первый кто рассуждая о Маркет - мейкерах, упрощает их деятельность или сравнивает их с некими злодеями Крупными игроками занимающихся манипуляциями рынков. На фондовых биржах это крупные инвестиционные банки (например, Goldman Sachs, Morgan Stanley) как Вы думаете их интересуют сделки в один тик? На разных рынках по разному, задачи и техники принципиально одни. Отслеживая сделки на рынке в целях выявления крупных сделок для лучшего понимания ситуации и реализации в системах принятия решений, делю игроков условно на 3 категории: 1) Крупный игрок 2) Маркет-мейкер 3) Ретейл. Различие в поведении в торгах! имелось в виду именно это, поэтому подробно подчернил технический аспект. Касаемо ММ, хотя это специализированная участник, компания или и.банк, обязанные соблюдать строгие регуляторные требования, они тоже совершают ошибки. Давайте представим ситуацию набрана огромная позиция, а рынок пошел против, что на весах, штраф если заметят, или манипуляция во спасение добра. И таких ситуаций множество. И это только моя точка зрения в основе которой, методологии Ричарда Вайкоффа (Wyckoff) с его композитным игроком, решения как считать каждый принимает сам.
VPM написал: nikolz, На форуме существует некая путаница в понятиях, и Вы не первый кто рассуждая о Маркет - мейкерах, упрощает их деятельность или сравнивает их с некими злодеями Крупными игроками занимающихся манипуляциями рынков. На фондовых биржах это крупные инвестиционные банки (например, Goldman Sachs, Morgan Stanley) как Вы думаете их интересуют сделки в один тик? На разных рынках по разному, задачи и техники принципиально одни. Отслеживая сделки на рынке в целях выявления крупных сделок для лучшего понимания ситуации и реализации в системах принятия решений, делю игроков условно на 3 категории: 1) Крупный игрок 2) Маркет-мейкер 3) Ретейл. Различие в поведении в торгах! имелось в виду именно это, поэтому подробно подчернил технический аспект. Касаемо ММ, хотя это специализированная участник, компания или и.банк, обязанные соблюдать строгие регуляторные требования, они тоже совершают ошибки. Давайте представим ситуацию набрана огромная позиция, а рынок пошел против, что на весах, штраф если заметят, или манипуляция во спасение добра. И таких ситуаций множество. И это только моя точка зрения в основе которой, методологии Ричарда Вайкоффа (Wyckoff) с его композитным игроком, решения как считать каждый принимает сам.
Я лишь рассказал кто такие ММ на московской бирже. На сайте биржи есть все условия и тарифы сколько и за что биржа платит. не имеет значение какой ММ крупный или мелкий. ММ - это тот, кому платит биржа за игру на бирже. ММ оказывает платную услугу бирже - это главное. Всем остальным биржа оказывает платную услугу. Все остальные признаки игроков -большие маленькие банки не банки , никакого отношения к понятию ММ не имеют
nikolz, Все это верно, это не предмет обсуждения. ММ это прежде всего коммерческий проект, целью которого является извлечение прибыли, как и любой другой коммерческой организации. Обладая значительными средствами, набирают большие позиции которые, оставляя следы на графике, а значить могут повести рынок за собой или держать его в диапазоне. Это интересует трейдера, отвечая на вопрос в какую сторону держать позицию, и уж совсем не интересно сколько заработал ММ. Именно это поведение как крупного игра их отличает. Вы можете даже конкретные алгоритмы найти в сети. Обладая дополнительной информацией они строят свои торговые стратегии, свой бизнес.
VPM написал: nikolz, Все это верно, это не предмет обсуждения. ММ это прежде всего коммерческий проект, целью которого является извлечение прибыли, как и любой другой коммерческой организации. Обладая значительными средствами, набирают большие позиции которые, оставляя следы на графике, а значить могут повести рынок за собой или держать его в диапазоне. Это интересует трейдера, отвечая на вопрос в какую сторону держать позицию, и уж совсем не интересно сколько заработал ММ. Именно это поведение как крупного игра их отличает. Вы можете даже конкретные алгоритмы найти в сети. Обладая дополнительной информацией они строят свои торговые стратегии, свой бизнес.
Вы не поняли. Я утверждаю, что понятие (кличка) "MM" связано лишь с оказанием платных услуг биржи. Это никак не связано ни со следами, ни с размером ни с чем другим . Если игрок не оказывает платные услуги бирже, то он не ММ. ---------------- Вы напридумывали кучу признаков для ММ, а реально существует лишь один - платная услуга бирже.
nikolz, Все я прекрасно понял. Смею предположить, Ваши торговые стратегии, видимо не выходят за пределы технологий "скальпинга", отсюда и кругозор. Выше Вы опубликовали участников заключивших договора, Вам наименования организаций не о чем не говорят? Именно они гоняются за тиками? Вы просто посмотрите на ликвидность в стаканах, и на финансовые возможности компаний обеспечивающих эту ликвидность. Что делать с остальными финансами? Могу предположить, что под скапинг выделяется не большая доля активного капитала на котором и крутятся HFT-алгоритмы, выдели 1% а что делать с 99% средств? Кстати, на эту же проблему эффективности, натолкнулся у себя в своих среднесрочных стратегиях, суть в следующем: есть 100% торговый капитал, по правилам риск менеджмента активный не более < 25%, что означает > 75% т. капитала лежит просто в обеспечении сделки, не плохо бы часть покрутить в скальперских стратегиях. Касаемо придумок все за долго до меня, стратегии опубликованы, на классику жанра указал выше. И никаких кличек, терминология применяется разная но это для упрощения в пониманиях, сегодня модная есть "смарт мани", там своя, у классиков своя, Суть одна. Касаемо следов не только на ценовых графиках отслеживаются, но часто в стакане, такой объем можно видеть, так как рассчитываемся по определенным правилам для данного эмитента то есть алгоритмический. Такие объемы определяются, и от них строятся разные стратегии. Платная услуга биржи, это не признак ММ, это один из источников дохода ММ. Даже мне раньше прилетало от биржи.
VPM написал: nikolz, Все я прекрасно понял. Смею предположить, Ваши торговые стратегии, видимо не выходят за пределы технологий "скальпинга", отсюда и кругозор. Выше Вы опубликовали участников заключивших договора, Вам наименования организаций не о чем не говорят? Именно они гоняются за тиками? Вы просто посмотрите на ликвидность в стаканах, и на финансовые возможности компаний обеспечивающих эту ликвидность. Что делать с остальными финансами? Могу предположить, что под скапинг выделяется не большая доля активного капитала на котором и крутятся HFT-алгоритмы, выдели 1% а что делать с 99% средств? Кстати, на эту же проблему эффективности, натолкнулся у себя в своих среднесрочных стратегиях, суть в следующем: есть 100% торговый капитал, по правилам риск менеджмента активный не более < 25%, что означает > 75% т. капитала лежит просто в обеспечении сделки, не плохо бы часть покрутить в скальперских стратегиях. Касаемо придумок все за долго до меня, стратегии опубликованы, на классику жанра указал выше. И никаких кличек, терминология применяется разная но это для упрощения в пониманиях, сегодня модная есть "смарт мани", там своя, у классиков своя, Суть одна. Касаемо следов не только на ценовых графиках отслеживаются, но часто в стакане, такой объем можно видеть, так как рассчитываемся по определенным правилам для данного эмитента то есть алгоритмический. Такие объемы определяются, и от них строятся разные стратегии. Платная услуга биржи, это не признак ММ, это один из источников дохода ММ. Даже мне раньше прилетало от биржи.
Не надо переходить на личности. Вы не угадаете , какими стратегиями я занимаюсь. смею заверить Вас, что все что Вы написали на форуме, как некоторое открытие для вас я изучил примерно 20 лет назад и все это уже применял в своих стратегиях. Я вам пытаюсь сказать что термин "маркет-мейкер" никак не связан ни со стратегиями ни с тиками ни с HFT Он связан лишь с оказанием услуг бирже. И ВСЕ --------------------- В той таблице, которую я вам привел с сайта биржи есть брокер БКС . Вы полагаете что БКС гоняется за тиками и поэтому Вы его называете ММ? ----------------
nikolz, Вы опять правы, мои предположения и понимание не есть "истина в последней инстанции", и я не отношу себя к "гуру", бывает ошибаюсь. Мне просто не понятно, что на специализированном форуме проходится рассуждать про объективные вещи. Да по мере присутствия на бирже учусь и набираюсь опыта, им делюсь и обсуждаю.
Цитата
nikolz написал: Вы полагаете что БКС гоняется за тиками и поэтому Вы его называете ММ?
Вы зачем ставите все "с ног на голову"? Ведь это Ваше утверждение.
Цитата
nikolz написал: Я утверждаю, что понятие (кличка) "MM" связано лишь с оказанием платных услуг биржи. Это никак не связано ни со следами, ни с размером ни с чем другим .
ММ это прежде всего коммерческий проект, целью которого является извлечение прибыли, как и любой другой коммерческой организации. Обладая значительными средствами, набирают большие позиции которые, оставляя следы на графике, а значить могут повести рынок за собой или держать его в диапазоне. Это интересует трейдера, отвечая на вопрос в какую сторону держать позицию, и уж совсем не интересно сколько заработал ММ. Именно это поведение как крупного игра их отличает. Вы можете даже конкретные алгоритмы найти в сети. Обладая дополнительной информацией они строят свои торговые стратегии, свой бизнес.
"Что написано пиром, то не вырубить топором". Касаемо моего подхода, читайте выше, там есть и формализация понятия о чем я рассуждаю, а рассуждаю я о контрагентах в сделках, как их можно формализовать в алгоритмических стратегиях.
Касаемо обработки собственных сделок, была а возможно и есть программа написана на qpl, называется Калькулятор уровней позиции: (q_calc) автор Николай Морошкин. На ней учился переписывая на луа логику. Выкладываю как возможный пример обработки сделок, просто в нем есть четкая логика, на ошибки нужно проверять.
Код
function detect_position()
--[[ Проверки статуса заявок (1-й и 2-й биты flags):
"Активна": bit.band(order.flags, 1) > 0
"Неактивна" (исполнена либо снята): bit.band(order.flags, 1) == 0
"Исполнена": bit.band(order.flags, 1) == 0 и bit.band(order.flags, 2) == 0
"Снята": bit.band(order.flags, 1) == 0 и bit.band(order.flags, 2) > 0
Нас интересуют два флага:
OF_ACTIVE = 0x01
OF_KILL = 0x02
--]]
local ord = "orders"
local max_numorder = getNumberOf("orders")
-- Отслеживаем количество ордеров
Log:trace('detect_position: отслеживаю размер массива '
.. ' getNumberOf =' .. tostring(max_numorder)
.. ' index =' .. tostring(max_numorder-1)
.. ' / o_index = ' .. tostring(o_index)
.. ' save_needed =' .. tostring(save_needed))
-- Функция для поиска ордеров
local function myFind(A, C, S, F)
return (A == ACCOUNT and C == CLASSCODE and S == SECCODE
and bit.band(F, 0x2) == 0 and bit.band(F, 0x1) == 0)
end
-- Поиск ордеров с нужными фильтрами
local iItems = SearchItems("orders", 0, max_numorder - 1, myFind, "account,class_code,sec_code,flags")
-- Проверка на пустой результат
if not iItems or #iItems == 0 then
Log:trace('ERROR: SearchItems вернул пустой результат')
return false
end
Log:trace('detect_position: всего элементов ' .. tostring(#iItems) .. ' последний ордер: ' .. tostring(iItems[#iItems]))
-- Если еще не инициализировано
if initialized == 0 then
initialized = -1
return
end
-- Обработка ордеров
for i = o_index, #iItems do
local order = getItem("orders", iItems[i])
if not order or type(order) ~= "table" then return false end
-- Определение флагов состояния ордера
local OF_ACTIVE = bit.band(order.flags, 1) > 0
local NOT_ACTIVE = bit.band(order.flags, 1) == 0
local OF_FILL = bit.band(order.flags, 1) == 0 and bit.band(order.flags, 2) == 0
local OF_KILL = bit.band(order.flags, 1) == 0 and bit.band(order.flags, 2) > 0
if order.account == ACCOUNT and order.class_code == CLASSCODE and order.sec_code == SECCODE
and (OF_FILL or OF_ACTIVE) and not Orders[order.order_num] then
Orders[order.order_num] = os.time() -- Запоминаем время
-- Получаем информацию о заказе
local order_n = order.order_num
local order_dt = order.datetime
local order_d = get_date(order_dt) -- Дата
local order_t = get_time(order_dt) -- Время
last_tradedate = order_d
local order_b = order.balance
local order_q = order.qty - order_b
local order_p = order.price
local order_op = bit.band(order.flags, 0x4) == 0 and 'BUY' or 'SELL'
-- Логирование активных ордеров
if OF_ACTIVE then
Log:trace(NAME_OF_STRATEGY .. ' ' .. i .. ' ACTIVE лимитная заявка по ' .. order.sec_code
.. ' number: ' .. tostring(order_n)
.. ' ' .. tostring(order_d)
.. ' ' .. tostring(order_t)
.. ' ' .. tostring(order_op)
.. ' ' .. tostring(order_q) .. ' (' .. tostring(order_b) .. ')'
.. ' ' .. tostring(order_p))
end
-- Обработка исполненных ордеров
if OF_FILL then
Log:trace(NAME_OF_STRATEGY .. ' ' .. i .. ' Исполнена лимитная заявка по ' .. order.sec_code
.. ' ' .. tostring(order_d)
.. ' ' .. tostring(order_t)
.. ' ' .. tostring(order_op)
.. ' ' .. tostring(order_q) .. ' (' .. tostring(order_b) .. ')'
.. ' ' .. tostring(order_p)
.. ' number: ' .. tostring(order_n))
local trade_q = 0
local trade_p = 0
local exchange_comission = 0
-- Поиск сделок, соответствующих ордеру
for trades_i = 0, getNumberOf("trades") - 1 do
local trade = getItem("trades", trades_i)
if trade.order_num == order_n then
last_order_id = order_n
local trade_d = get_date(trade.datetime)
local trade_t = get_time(trade.datetime)
local qq = trade.qty
local pp = trade.price
trade_q = trade_q + qq
trade_p = trade_p + (qq * pp)
exchange_comission = exchange_comission + trade.exchange_comission
end
end
if trade_q ~= 0 then
trade_p = trade_p / trade_q
exchange_comission = exchange_comission / trade_q
end
-- Проверка на рассинхронизацию заявок и сделок
if order_q ~= trade_q then
Log:trace("Рассинхронизация заявок и сделок: " .. tostring(order_n)
.. ", " .. tostring(order_q) .. "/" .. tostring(trade_q))
message("Рассинхронизация заявок и сделок: " .. tostring(order_n)
.. ", " .. tostring(order_q) .. "/" .. tostring(trade_q))
end
-- Запись в журнал
Log:trace('Получаю тек. позицию: '
.. " " .. tostring(pos.dir)
.. ' ' .. tostring(pos.qty)
.. ' ' .. tostring(pos.op)
.. ' ' .. tostring(pos.cap)
.. ' ' .. tostring(pos.be))
Log:trace('Получаю изменения в позиции: '
.. ' ' .. tostring(qcap)
.. ' order_op=' .. tostring(order_op)
.. ' order_q=' .. tostring(order_q)
.. ' order_b=' .. tostring(order_b)
.. ' order_p=' .. tostring(order_p)
.. ' / trade_q=' .. tostring(trade_q)
.. ' trade_p=' .. tostring(trade_p))
-- Управление позицией
local log_action = ""
if pos.dir == "n" then
pos.dir, pos.qty, pos.op, pos.cap, pos.be, pos.open = set_position(order_op, trade_q, trade_p)
write_journal(order_op, qcap, trade_q, trade_p, trade_datetime)
log_action = "Открытие позиции " .. tostring(pos.dir) .. ' ' .. tostring(pos.qty) .. ' ' .. tostring(pos.op)
Log:trace(i .. ' ' .. log_action)
save_needed = 1
elseif (pos.dir == "L" and order_op == "BUY") or (pos.dir == "S" and order_op == "SELL") then
pos.op = pos.op * pos.qty + trade_p * trade_q
pos.qty = pos.qty + trade_q
pos.op = pos.op / pos.qty
write_journal(order_op, -1, trade_q, trade_p, trade_datetime)
log_action = "Наращивание позиции " .. tostring(pos.dir) .. tostring(pos.qty)
Log:trace(i .. ' ' .. log_action)
save_needed = 1
else
if trade_q == pos.qty then
pos.dir, pos.qty, pos.op, pos.cap, pos.be, pos.open = "n", 0, 0, 0, 0, bar.open
write_journal(order_op, 0, trade_q, trade_p, trade_datetime)
log_action = "Закрытие позиции " .. tostring(pos.dir) .. ' ' .. tostring(pos.qty)
Log:trace(i .. ' ' .. log_action)
end
save_needed = 1
end
end
end
end
end
Не знаю почему не получается сворачивать окно у меня. Подскажите последовательность нажатия конок? Хотел предложить на обсуждение еще один вариант, обработки сделок уже т. всех сделок с использованием очереди. По факту даже два варианта. 1) обрабатываем в маин. 2) асинхронный. Как раз перерабатываю, чтобы модуль добавить в программу.
Коллбек как источник данных, для асинхронной обработки данных. Довел вариант до рабочего, в качестве источника данных OnAllTrade, получаем таблицу и переносим расчеты, не в маин, в сопрограмму. Такой подход не блокирует выполнение других операций программы, если количество сделок большое, или сделка обрабатывается долго, которые запущены в процессе. Производительность и нагрузки просто супер. Задание паузы между итерациями обработки позволяет контролировать частоту обработки данных, что полезно для предотвращения перегрузки системы, а также задает временные промежутки для накопления данных в очередь. Этот подход позволяет не только улучшить структуру кода, но и легко расширять систему с новыми метриками и функциональностью. Каждый компонент изолирован и отвечает только за свою часть. Легко добавлять или менять логику внутри каждого модуля, не влияя на другие части системы. А также, можно добавлять новые метрики или алгоритмы, расширяя существующие возможности самой программы. Собраны метрики и алгоритмы в отдельные модули. Каждый модуль может экспортировать только необходимые функции и данные, позволяя другим частям системы использовать их через интерфейсы, что должно помочь избежать излишней зависимости между компонентами. Метрики можно групировать по стратегиям. Система принятия решений будет интегрировать метрики, анализировать их с использованием различных стратегий и на основе результатов принимать решение о торговых действиях. Основными компонентами такой системы принятия решений будут: 1. Метрики – используем различные метрики для анализа данных. 2. Стратегии – каждая стратегия (скальпинг, трендовая торговля, арбитраж) будет использовать различные метрики для принятия решений. 3. Алгоритм принятия решений – будет выбирать, какая стратегия должна быть использована в текущих условиях рынка и какое действие (купить/продать) должно быть выполнено. 4. Система обработки данных – будет собирать данные (например, цены и объемы), передавать их в соответствующие стратегии и использовать метрики для анализа. В моем случае придется, переосмыслить архитектуру основной программы - добавить универсальности, но и наконец то, выхожу на однотипную структуру данных для такой программы, под гордым названием с большой буквы Робот. Пока, Всем хорошей торговли!