Есть в Lua функция для расчёта ГО заявки по заданной цене (та циферка, что в поле Объем ГО в окне ввода заявки)?
QUIK clients support
Сообщений: Регистрация: 27.01.2015
03.06.2020 13:59:41
Цитата
Незнайка написал: Есть в Lua функция для расчёта ГО заявки по заданной цене (та циферка, что в поле Объем ГО в окне ввода заявки)?
Добрый день.
К сожалению, получить Объем ГО с формы ввода заявки нельзя.
Пользователь
Сообщений: Регистрация: 30.05.2020
03.06.2020 14:36:25
В QUIK есть же эта функция. Можете сделать её доступной в Lua?
Пользователь
Сообщений: Регистрация: 27.01.2017
03.06.2020 15:58:45
Попробуйте что-то типа такого. Передается базовое текущее ГО по направлению сделки, цена сделки.
Код
---@param Sec table
---@param go number
---@param deal_price number
---@param Type string SELL|BUY
local function CalcPriceGO(Sec, go, deal_price, Type)
if type(Sec) ~= 'table' then error(("bad argument Sec (table expected, got %s)"):format(type(Sec)),2) end
if type(go) ~= 'number' then error(("bad argument go (number expected, got %s)"):format(type(go)),2) end
if type(deal_price) ~= 'number' then error(("bad argument deal_price (number expected, got %s)"):format(type(deal_price)),2) end
if Type ~= 'BUY' and Type ~= 'SELL' then error(("bad argument Type (string 'SELL' or 'BUY' expected, got %s)"):format(tostring(Type)),2) end
local status, res = pcall(function()
if getParamEx(Sec.CLASS_CODE, Sec.SEC_CODE, "CLPRICE").result ~= '1' then
log.warn([[ Для точного расчета ГО необходимо включить в поток данных параметр "Котировка последнего клиринга".
Сейчас он не включен. Будет взято базовое ГО]])
return go
end
if getParamEx(Sec.CLASS_CODE, Sec.SEC_CODE, "PRICEMAX").result ~= '1' then
log.warn([[ Для точного расчета ГО необходимо включить в поток данных параметр "Максимально возможная цена". Сейчас он не включен.
Сейчас он не включен. Будет взято базовое ГО]])
return go
end
if getParamEx(Sec.CLASS_CODE, Sec.SEC_CODE, "PRICEMIN").result ~= '1' then
log.warn([[ Для точного расчета ГО необходимо включить в поток данных параметр "Минимально возможная цена". Сейчас он не включен.
Сейчас он не включен. Будет взято базовое ГО]])
return go
end
local priceKoeff = Sec.STEPPRICE/Sec.SEC_PRICE_STEP
local cl_price = tonumber(getParamEx(Sec.CLASS_CODE,Sec.SEC_CODE,'CLPRICE').param_value) or 0
local max_price = tonumber(getParamEx(Sec.CLASS_CODE,Sec.SEC_CODE,'PRICEMAX').param_value) or 0
local min_price = tonumber(getParamEx(Sec.CLASS_CODE,Sec.SEC_CODE,'PRICEMIN').param_value) or 0
if cl_price==0 or max_price == 0 or min_price == 0 then return go end
local L2 = (max_price-min_price)*math_pow(10, Sec.SCALE)
local R = (go/(L2*priceKoeff) - 1)*100
local sign = Type == 'BUY' and -1 or 1
return go + sign*(cl_price - deal_price)*priceKoeff*(1 + R/100)
end)
if not status then
log.error('Error CalcPriceGO: '..tostring(res))
return go
end
return res
end
означает лишь то, что для данной бумаги существует параметр с именем param_name, не более. И не гарантирует, что он транслируется на клиентское место или что он хотя бы заказан. И в общем случае проверить транслируется ли параметр не представляется возможным.
Вот эту строку вообще не понял:
Код
local L2 = (max_price-min_price)*math_pow(10, Sec.SCALE)
Вот так, наверное, должно быть, тогда совпадает с квиковскими значениями в окне ввода заявки:
Код
local L2 = max_price-min_price
НО! Написал скрипт, который считает ГО по вашей формуле (с моей поправкой) и сравнил с фактически блокируемым ГО под заявку. Значения не совпадают от слова совсем: В таблице: БГО - ГО продавца, взятое из ТТТ Мин., Макс. - соответственно мин. и макс. возможные цены ГО Buy - Фактически заблокированное ГО под заявку на покупку по мин. цене ГО Sell - Фактически заблокированное ГО под заявку на продажу по макс. цене Buy - ГО, рассчитанное по (с моей поправкой) на покупку по мин. цене
Вниманию саппорта: Функция ParamRequest возвращает true даже если параметр не удалось заказать. Чтобы убедиться в этом достаточно включить галку «С учетом настроек, выбранных пользователем вручную через пункт меню Система/Заказ данных/Поток котировок» и вызвать ParamRequest с параметром, которого ещё нет в списках.
Значение в поле Объем ГО в окне ввода заявки не совпадает с фактически блокируемым ГО под заявку по той же цене. См. табличку выше. В окне ввода заявки транслируется значение Buy +- 1 копейка, а блокируется ГО Buy
Пользователь
Сообщений: Регистрация: 30.05.2020
06.06.2020 00:28:55
*БГО - ГО покупателя, взятое из ТТТ
Пользователь
Сообщений: Регистрация: 27.01.2017
06.06.2020 08:50:07
В расчете L2 нет ошибки. Он ведется в пунктах (т.к. далее пункты переводятся в рубли, через умножение на priceKoeff), поэтому и умножается на размерность инструмента. Проверьте, что передаете правильные значения по направлению. Если покупка, то БГО покупателя и наоборот. Значения же разные.
getParamEx возвращает строку "1" если параметр получен и строку "0" если нет. Если не ошиблись с написание параметра (а этом можно сделать организовав словарь), то возврат "0" или не равно "1" - это значит параметр не транслируется.
Пользователь
Сообщений: Регистрация: 27.01.2017
06.06.2020 10:40:58
Впрочем, Вы правы. Я выдернул часть расчета из другой части кода и не увидел, что здесь перевод в деньги от цены, не от пунктов. Т.к. большинство фьючерсов имеют цену как целое число, то это не влияло на результат. Да, надо убрать приведение цены к целому значению.
Я писал это основываясь на этой статье:
Пользователь
Сообщений: Регистрация: 30.05.2020
06.06.2020 21:45:54
Цитата
Nikolay написал: getParamEx возвращает строку "1" если параметр получен и строку "0" если нет.
Проведите небольшой эксперимент: включите галку «С учетом настроек, выбранных пользователем вручную через пункт меню Система/Заказ данных/Поток котировок» и попробуйте получить значение параметра, который не добавлен в списки получаемых параметров (Заказ данных/Поток котировок...) getParamEx вернёт таблицу с result == "1", но без значения самого параметра.
Пользователь
Сообщений: Регистрация: 30.05.2020
06.06.2020 21:56:21
Цитата
Nikolay написал: Я писал это основываясь на этой статье:
Чего-то я не понимаю. Возьмём к примеру, SiM0: ГО покупателя = 5577,68 ГО продавца = 5595,86 Макс.возм.цена = 71598 Мин.возм.цена = 65454
2L = Макс.возм.цена - Мин.возм.цена = 71598 - 65454 = 6144, что меньше ГО Исходя из формулы в статье радиус валютного курса R получается отрицательный: -9.1% Всё так?
Пользователь
Сообщений: Регистрация: 30.05.2020
06.06.2020 22:01:24
А для EDM0 ГО = 3030 руб. 2L = 0,0614 пунктов, что в переводе в рубли 4200 R получается: -28% В чём подвох?
написал: getParamEx возвращает строку "1" если параметр получен и строку "0" если нет.
Проведите небольшой эксперимент: включите галку «С учетом настроек, выбранных пользователем вручную через пункт меню Система/Заказ данных/Поток котировок» и попробуйте получить значение параметра, который не добавлен в списки получаемых параметров (Заказ данных/Поток котировок...) getParamEx вернёт таблицу с result == "1", но без значения самого параметра.
Такой варинт настроек не самый удачный для использования скриптов. Нельзя гаратнтировать, что пользователь не сменит (закроет) таблицу и поток данных исчезнет. Поэтому есть процедуры: ParamRequest, CancelParamRequest.
Пользователь
Сообщений: Регистрация: 30.05.2020
07.06.2020 10:46:22
Nikolay, Я вам просто хочу донести, что result == "1" не гарантирует, что параметр включен в поток данных. Если же result ~= "1", то вы не найдёте его в списках доступных параметров.
Пользователь
Сообщений: Регистрация: 27.01.2017
07.06.2020 10:59:18
По расчету ГО советую еще ознакомится с древней темой на форуме биржи
Пользователь
Сообщений: Регистрация: 27.01.2017
07.06.2020 11:01:29
Цитата
Незнайка написал: , Я вам просто хочу донести, что result == "1" не гарантирует, что параметр включен в поток данных. Если же result ~= "1", то вы не найдёте его в списках доступных параметров.
Да, это так. Но я свои скрипты пишу из расчета, что включена настройка независимого получения данных, что отмечаю в описании и инструкции.
QUIK clients support
Сообщений: Регистрация: 27.01.2015
08.06.2020 08:51:19
Цитата
Незнайка написал: В QUIK есть же эта функция. Можете сделать её доступной в Lua?
Здравствуйте!
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Пользователь
Сообщений: Регистрация: 30.05.2020
10.06.2020 17:24:09
Egor Zaytsev, вы дальше читайте: ваш Квик неправильно считает ГО
Незнайка написал: , вы дальше читайте: ваш Квик неправильно считает ГО
И про ParamRequest я для кого ?
Добрый день.
Не совсем понятно почему не правильно? У Вас вопрос к тому, что на продажу и покупка разное ГО?
Пользователь
Сообщений: Регистрация: 30.05.2020
15.06.2020 18:37:36
Т.е., вас не смущает, что в окне ввода заявки указывается одно значение ГО, а резервируется под эту заявку совсем другая величина?
Пользователь
Сообщений: Регистрация: 30.01.2015
16.06.2020 06:43:16
Цитата
Незнайка написал: Т.е., вас не смущает, что в окне ввода заявки указывается одно значение ГО, а резервируется под эту заявку совсем другая величина?
читайте первоисточники:
Пользователь
Сообщений: Регистрация: 30.01.2015
16.06.2020 06:47:37
здесь руководство:
здесь софт:
Пользователь
Сообщений: Регистрация: 30.01.2015
16.06.2020 07:04:56
в документации указанной выше Вы узнаете что ГО зависит от направления сделки: Эффекты: • Асимметричное ГО на покупку и продажу • Увеличение ГО по однонаправленным позициям из-за учета процентного риска • Снижение изменений из-за влияния IR с увеличением срока • Снижение ГО по позициям в ММС и по «Календарным спредам» ---------------------
QUIK clients support
Сообщений: Регистрация: 27.01.2015
16.06.2020 07:53:51
Цитата
Незнайка написал: Т.е., вас не смущает, что в окне ввода заявки указывается одно значение ГО, а резервируется под эту заявку совсем другая величина?
Добрый день.
В форме ввода заявки ГО рассчитывается, оно не "едет" напрямую из таблицы текущих торгов в форму ввода заявки.
Egor Zaytsev написал: В форме ввода заявки ГО рассчитывается, оно не "едет" напрямую из таблицы текущих торгов в форму ввода заявки. Считаете по формуле.
У вас сходится ГО, рассчитанное по этой формуле, с тем, что считает квик?
Пользователь
Сообщений: Регистрация: 30.01.2015
27.06.2020 18:34:31
ГО считает не квик, а программа от биржи. См. ссылку выше. Все правила и формулы биржевых торгов устанавливает биржа.
Пользователь
Сообщений: Регистрация: 30.05.2020
05.07.2020 23:59:16
nikolz, дружище, ты читать умеешь? Тебе сотрудник ТП русским языком написал:
Цитата
Egor Zaytsev написал: В форме ввода заявки ГО рассчитывается, оно не "едет" напрямую из таблицы текущих торгов в форму ввода заявки.
Пользователь
Сообщений: Регистрация: 30.05.2020
06.07.2020 00:05:42
Egor Zaytsev, какая ещё информация необходима, чтобы начать разбор проблемы "QUIK неверно рассчитывает Объем ГО заявки и, => максимальное возможное количество лотов в заявке" ?
QUIK clients support
Сообщений: Регистрация: 27.01.2015
20.07.2020 11:25:47
Цитата
Незнайка написал: , какая ещё информация необходима, чтобы начать разбор проблемы "QUIK неверно рассчитывает Объем ГО заявки и, => максимальное возможное количество лотов в заявке" ?
Добрый день.
Максимальное кол-во у Вас не рассчитано возможно потому что не подставлен торговый счет на форме ввода заявки, либо не включена опция пункт меню Система/Настройки/Основные настройки/Программа/Получение данных/ "Исходя из настроек открытых пользователем таблиц"
Что касается объема ГО на форме ввода заявки, то выше выложили формулу для расчета, подставьте значения и проверьте результат.
Пользователь
Сообщений: Регистрация: 30.05.2020
20.07.2020 16:36:14
Egor Zaytsev, то ли я плохой рассказчик, то ли вы... плохой читатель. Попробуем ещё раз. Открываем Руководство пользователя QUIK и читаем:
Цитата
Ввод заявок на Срочном рынке FORTS «Объем ГО» – совокупный размер ГО, который блокируется по заявке исходя из количества контрактов и настроек брокера.
Проверяем, ставим заявку и сравниваем со значением Тек. чист. поз. из таб. Ограничения по клиентским счетам. В сообщении привёл скрины с реального счёта, не демо. Даже обвёл красненьким, на что обратить внимание. Видите, циферки не совпадают?
QUIK clients support
Сообщений: Регистрация: 27.01.2015
24.07.2020 09:51:24
Добрый день.
Информацию проверили.
1. У Вас должна быть версия не ниже 8.7.1. Ранее действительно Объем ГО мог не верно считаться, но
не верно он считался именно исходя из наших формул. 2. В текущий момент Объем ГО может не совпадать с биржевыми расчетами, так как у нас представлена упрощенная формула расчета.
Пользователь
Сообщений: Регистрация: 30.05.2020
24.07.2020 10:24:40
Цитата
Egor Zaytsev написал: Также убедитесь, что у Вас версия рабочего места 8.2 и выше.
Цитата
Egor Zaytsev написал: 1. У Вас должна быть версия не ниже 8.7.1.
Что-то изменилось в расчёте ГО в 8.7.1 по сравнению с 8.2?
написал: Также убедитесь, что у Вас версия рабочего места 8.2 и выше.
Цитата
написал: 1. У Вас должна быть версия не ниже 8.7.1.
Что-то изменилось в расчёте ГО в 8.7.1 по сравнению с 8.2?
В версии 8.2 как раз и была исправлена ошибка некорректного расчета объема ГО в форме ввода заявки.
Пользователь
Сообщений: Регистрация: 30.05.2020
31.07.2020 18:03:50
В первом приближении ГО можно рассчитать по формуле: Покупка: ГО = ГО_покупателя - (РЦ - Цена_сделки) * Стоимость_шага_цены / Мин_шаг_цены * (1 + R / 100) Продажа: ГО = ГО_продавца + (РЦ - Цена_сделки) * Стоимость_шага_цены / Мин_шаг_цены * (1 + R / 100) где R - радиус валютного курса Для контрактов, шаг цены которых рассчитывается в рублях, R = 0
Судя по значениям, QUIK рассчитывает R для всех контрактов, в т.ч. рублёвых, по формуле, приведённой в сообщении #4. Не знаю, как определить R, но после релиза Спектры 6.0 он точно не рассчитывается по той формуле. Например, на сегодня для USD R = 6% Если считать по формуле для RIU0 получается 5,44%, для BRQ0 -19,7%. Короче, невпопад.
При цене сделки, близкой к верхнему или нижнему лимиту, ГО считается как-то иначе. Как именно, не разобрался ( В методике расчёта ГО не нашёл, плохо искал наверное.
QUIK clients support
Сообщений: Регистрация: 27.01.2015
24.08.2020 15:44:26
Добрый день.
Если все таки у вас не верно считается объем ГО на форме ввода заявки, то просьба предоставить архив рабочего места на момент проблемы и ваши расчеты, по каким формулам и какие значения подставляете.
Пользователь
Сообщений: Регистрация: 30.05.2020
25.08.2020 15:08:25
Egor Zaytsev, неужели так сложно скачать архив с вашего фтп, подключиться к серверу брокера и проверить?
Расчёты на сегодня (25.08 после клиринга 14:00):
Для SRU0: РЦ: 23 058 ГО покупателя: 4 034,40 ГО продавца: 4 086,80
Считаем по , поскольку шаг цены расччитывается в рублях, R = 0
Покупка по цене 22 058: В форме ввода заявки QUIK показывает: 3040,71 По формуле:
Код
ГО = 4034,40 - (23058 - 22058) * 1 / 1 = 3034,40
Столько же блокируется биржей*.
Продажа по цене 24 058: В форме ввода заявки: 3080,20 По формуле:
Код
ГО = 4086,80 + (23058 - 24058) * 1 / 1 = 3086,80
Столько же блокируется биржей*.
Для BRU0: РЦ: 45,44 ГО покупателя: 7 240,57 ГО продавца: 7 264,32 Шаг цены: 0,01 Ст. шага цены: 7,46714 R: 6
Покупка по цене 44,44: В форме ввода заявки: 6641,19 По формуле:
* значение Тек. чист. поз. из таблицы Ограничения по клиентским счетам
У нас нет доступа к серверу брокера, поэтому нам нужен архив вашего рабочего места QUIK.
Пользователь
Сообщений: Регистрация: 30.05.2020
16.09.2020 18:58:22
Цитата
Egor Zaytsev написал: У нас нет доступа к серверу брокера
Как же вы работаете?
Правильнее всё же будет уточнить актуальную формулу расчёта для текущего релиза спектры у сотрудников МБ и исправить у себя.
QUIK clients support
Сообщений: Регистрация: 27.01.2015
18.09.2020 11:02:50
Здравствуйте!
Ваше обращение получено, проблема изучается. Постараемся в ближайшее время дать ответ.
QUIK clients support
Сообщений: Регистрация: 27.01.2015
29.09.2020 14:37:04
Добрый день, Вопрос изучили.
Расчет ГО для выставляемой заявки в форме ввода носит прежде всего информационный предварительный характер. В силу ряда причин мы не можем в точности повторить биржевой расчет. Расчет рисков и проверку покупательной способности по операциям срочного рынка МБ для конфигураций ПО QUIK, не использующих единую денежную позицию с фондовым рынком, выполняет полностью торговая система. Тем не менее, мы стараемся актуализировать этот расчетный алгоритм и устранять найденные ошибки. В данный момент мы признаем, что расчет ГО для фьючерсов, использующих радиус курса иностранных валют, может быть неточным. Данную ошибку мы исправим в одной из следующих версий клиентского места QUIK. Приносим извинения за доставленные неудобства и задержку с ответом.