getBuySellInfoEx

Внимание

Для участия в обсуждениях и оформления подписки на новые сообщения форума вам необходимо зарегистрироваться.
Главная » Основные форумы » Программирование на языке Lua
Страницы: Пред. 1 2 3 След.
RSS
getBuySellInfoEx
 
#51
16.02.2016 18:10:31
Ни разу не сложно привести расчет для второго примера.
Покупка по 70000, ниже расчетной цены (71550).
Имеем:

(2L – (РЦ – Ц)) / MinStep * MinStepPrice = ((75130 - 67970) - (71550 - 70000)) / 10 * 15.44570 = 8665.0377

... что без проблем соответствует значению ГО в примере (для 1000 контрактов). И конечно, снова без учета радиуса валютного курса.
 
 
#52
16.02.2016 18:20:51
Цитата
Stanislav Tvorogov написал:

Цитата
В реализованном алгоритме расчета ГО  для клиентского места QUIK       версии 7.0 пока не поддержан учет  радиуса курса валют. Это приводит      к  расхождению ГО по сравнению с  биржевым. Постараемся доработать       функционал в одной из следующих  версий.
Данная проблема относится к Валютному рынку и действительно имеет место быть. Мы работаем над ее устранением. Показатели же по Срочному и Фондовому рынкам рекомендуем проверять на актуальной версии терминала.
Цитата
Sergey Gorokhov написал:
Что касается учета радиуса курса валют, то на данный момент этот функционал пока еще не реализован.

Честно говоря, больше не хочется ходить по кругу.
 
 
#53
16.02.2016 18:25:29
Цитата
Sergey Gorokhov написал:
Что касается учета радиуса курса валют, то на данный момент этот функционал пока еще не реализован
Приходишь в магазин, уточняешь у продавцов работает ли купленная машина, отвечают: да мы несколько раз её проверили - работает!!  Идёшь на стенд, забрать её и видишь что нет колёс, спрашиваешь: в чём дело, вы же сказали что она работает? Да работает мы несколько раз проверили! :)

По такому поводу конкретный вопрос, Сергей как вы считаете при оценки максимальных количестве лотов по фьючерсу РТС, должна ли учитываться валютный рдиус?
а. НЕТ
б. ДА
в. Понятие не имею  
 
 
#54
16.02.2016 18:29:27
Роман,
Ответ уже был дан и повторять его не вижу смысла
 
 
#55
16.02.2016 18:35:22
Теперь немного конструктива. Для всех, кому актуально.
Для получения правильного размера ГО в текущей ситуации есть недорогой "костыль".
Можно использовать значение ГО в рублях, транслируемое в параметрах инструмента. Оно рассчитано биржей правильно, с учетом радиуса курса. Только его надо скорректировать, потому что оно "базовое", т.е. соответствует ГО в пунrтах = 2L и, соответственно, заявкам по расчетной цене (цене клиринга).

Например, у нас покупка по цене ниже лимита. Берем ГО в рублях, делим на 2L и умножаем на 2L – (РЦ – Ц), формула из методики.
Получаем правильное ГО.
 
 
#56
16.02.2016 18:37:18
Сергей, вы всё время пишите что функция работает на все 100% и в то же время говорите что радиус не учитывается, поэтому пожалуйста ответь окончательно и конкретно, что бы мы поняли вашу позицию!
 
 
#57
16.02.2016 18:37:45
Цитата
SDL написал:
Честно говоря, больше не хочется ходить по кругу.
К сожалению ответ сотрудника неверный
Отсутствие учета  радиуса курса валют относится конечно же к срочному рынку.
Приносим извинения за дезинформацию
 
 
#58
16.02.2016 18:55:53
Цитата
Роман написал:
Сергей, вы всё время пишите что функция работает на все 100% и в то же время говорите что радиус не учитывается, поэтому пожалуйста ответь окончательно и конкретно, что бы мы поняли вашу позицию!
Роман,
Вы спрашивали "корректно ли работает сейчас функция getBuySellInfoEx"
на что ответ, да сейчас она работает корректно. Вы использовали эту функцию для срочного рынка, а она предназначена для фондового.
согласно документации на терминал QUIK
* ПокупкаМаксимально возможное количество бумаг в заявке на покупку этого  инструмента на этом классе, исходя из лучшей цены предложения, без учета  комиссии торговой системы и комиссии брокера
* ПродажаМаксимально возможное количество бумаг в заявке на продажу этого  инструмента на этом классе, исходя из лучшей цены спроса, без учета комиссии  торговой системы и комиссии брокера
Касаемо CalcBuySell, да она сейчас не учитывает курс валют, как уже было сказано доработка уже делается, но еще не реализована.
 
 
#59
16.02.2016 19:06:30
Вот это уже ответ, с радиусом ещё и проблема в том, что в свойствах инструментов нет указаний, нужно ли его применить к данному инструменту или нет.

А вот про комиссии и биржевой сбор - это актуально, я его как раз и не учёл.

Тогда ждём полноценную и УНИВЕРСАЛЬНУЮ функцию getBuySellInfoEx и CalcBuySell!
 
 
#60
16.02.2016 19:07:44
Цитата
Sergey Gorokhov написал:
К сожалению ответ сотрудника неверный
Отсутствие учета  радиуса курса валют относится конечно же к срочному рынку.

Это радует, что наконец с этим вопросом разобрались. По поводу текущего положения нужно сказать следующее. В данном случае такая "частичная" реализация алгоритма ГО (во всяком случае на инструментах, привязанных к валютам) - всё равно, что отсутствие таковой полностью. Некорректно рассчитанное макс. количество контрактов может (но конечно, не во всех случаях) привести к превышению лимитов. И какой тогда смысл в этом расчете? Это всё равно, что залить полный бак бензина, но не залить масло: автомобиль одно не поедет.

По вопросу относительно функции CalcBuySell. Если я правильно понимаю, она должна возвращать значение, полностью идентичное рассчитываемому в окне ввода заявки. Давайте исходить из того, что лимиты придуманы биржей не для того, чтобы их нарушать. Поэтому чудес быть не должно. У меня есть следующее предположение, как это можно проверить. ГО с учетом радиуса курса больше, но ненамного - процентов на 15-20. Попробуйте ввести заявку, когда денежный лимит на счете в точности равен (или кратен) размеру ГО, рассчитанному терминалом. Идея понятна? Вполне возможно, лимита хватало, поэтому проблема с превышением не воспроизводилась.
 
 
#61
16.02.2016 19:26:54
Цитата
Роман написал:
с радиусом ещё и проблема в том, что в свойствах инструментов нет указаний, нужно ли его применить к данному инструменту или нет

Принципы расчета вариационной маржи и гарантийного обеспечения с использованием текущих курсов валют

В этом документе есть их перечень ("Контракты, предусматривающие данный алгоритм расчёта вариационной маржи").
И, конечно, в спецификации инструментов. Например, по RIxx: "Стоимость минимального шага цены Контракта соответствует 20 % от курса  доллара США по отношению к российскому рублю, установленному в  соответствии с Методикой ..."
 
 
#62
16.02.2016 19:32:56
SDL, ну это понятно - но зачем эти километры кода в скрипте писать и потом следить за их изменениями, Надёжней в параметрах инструмента это указывать и всё, а если функция CalcBuySell будет корректно отражать данные. то в принципе для меня и не актуально будет.
 
 
#63
16.02.2016 19:40:50
Цитата
Роман написал:
в параметрах инструмента это указывать
Если нужно не просто знать, а автоматизировать... Нет, параметра такого не могу назвать.
А зачем? См. выше мой способ расчета корректного ГО. Может подойдет?
 
 
#64
16.02.2016 20:19:36
Цитата
Если нужно не просто знать, а автоматизировать... Нет, параметра такого не могу назвать.
Все подходи и правильно, но конечно всё автоматизировать нужно, с этим ГО на заплатках все работает (хотя новый расчёт ГО ещё в середине прошлого года поменяли), какой смысл одними заплатками менять на другие. Так что решения косяка со стороны КВИК - уже  более чем крайне необходжио!!!  
 
 
#65
16.02.2016 22:10:26
з.ы можно конечно и "валютный шаг" использовать, но там я смотрю там и другие валюты есть, как бы не напороться на ошибку.  
 
 
#66
17.02.2016 00:27:39
SDL.  а вы уверенны что формула с радиусом верна? У меня очень высокое ГО получается, я ещё докупить могу?
 
 
#67
17.02.2016 01:08:17
Цитата
Роман написал:
формула с радиусом верна?

1. Методику нам дала биржа. Явных противоречий там вроде нет.
2. Если есть сомнения, легко посчитать самому и сравнить. Для цены, равной расчетной (посл. клиринга), должно получиться ГО, транслируемое в параметрах контракта.

Цитата
Роман написал:
У меня очень высокое ГО получается, я ещё докупить могу?

Макс. кол-во = Денежный лимит / ГО

ГО - обеспечение 1 контракта.
Если ГО увеличивается, то количество - ... что?
 
 
#68
17.02.2016 01:48:05
на бирже вообще другое объяснение: http://forum.moex.com/viewtopic.asp?t=30125  :cry: Вообще моразм какой-то, не кто не может указать реально проверенную формулу.
 
 
#69
17.02.2016 01:50:02
SDL, я не вижу примера от биржи, реально, я вижу только куски нарезанных методик взятых с разных документации.
 
 
#70
17.02.2016 01:52:08
На форуме самой биржи, запостил вопрос - надеюсь первоисточник пояснит.
 
 
#71
17.02.2016 03:49:08
SDL,а почему у вас 2L = 75130 - 67970 (это где-то 7000), в той же методички что вы сбрасывали там 2L = базовому ГО, а оно где то 13500?
 
 
#72
17.02.2016 04:01:23
наверное не 2L а просто L
 
 
#73
17.02.2016 10:34:04
Цитата
Роман написал:
на бирже вообще другое объяснение:  http://forum.moex.com/viewtopic.asp?t=30125    Вообще моразм какой-то, не кто не может указать реально проверенную формулу.
Несправедливое утверждение. Все примеры расчетов, что я приводил, в точности соответствуют объяснениям по этой ссылке. Если есть сомнения, готов разобрать конкретный пример, приводите данные.

Цитата
Роман написал:
SDL , я не вижу примера от биржи, реально, я вижу только куски нарезанных методик взятых с разных документации.
Методика изложена в нескольких документах, это правда. Но они не противоречат, а дополняют друг друга. Все здесь, в одном месте: http://moex.com/a186

Цитата
Роман написал:
SDL ,а почему у вас 2L = 75130 - 67970 (это где-то 7000), в той же методички что вы сбрасывали там 2L = базовому ГО, а оно где то 13500?
Потому что 2L - это ГО в пунктах, чтобы получить рубли, надо применить формулу
ГО = ГО_в_пунктах * (MisStepPrice / MinStep) * (1 + R / 100)

... которая приведена, в частности, и по указанной ссылке на форуме биржи.
Цитата
Роман написал:
наверное не 2L а просто L
Нет, заявке по расчетной цене соответствует значение именно 2L = Pmax - Pmin
 
 
#74
17.02.2016 15:28:13
Другой вариант: http://forum.moex.com/viewtopic.asp?t=30919
 
 
#75
17.02.2016 15:37:46
Цитата
Роман написал:
Другой вариант:  http://forum.moex.com/viewtopic.asp?t=30919

Правильный расчет, строго по этой методике. В чем он другой, я не могу понять? Можно конкретно сравнить и показать?
 
 
#76
17.02.2016 18:00:18
Цитата
SDL написал:
Цитата
Роман   написал:
Другой вариант:   http://forum.moex.com/viewtopic.asp?t=30919  
Правильный расчет, строго по этой методике. В чем он другой, я не могу понять? Можно конкретно сравнить и показать?
Да не совсем, там всплывают всё новые и новые подробности!
 
 
#77
17.02.2016 19:03:04
Цитата
Роман написал:
там всплывают всё новые и новые подробности!

Прочитал. Да, интересный поворот, ничего не скажешь. А "Алексей Ерпылев" там сотрудник биржи?
1. Ок, я задал вопрос брокеру, самому интересно стало. Но. Следует отметить:

["result_msg"]="Ошибка создания заявки. [GW][332] \"Нехватка средств по лимитам клиента.\"."
Это кто отлуп дает - брокер или всё-таки биржа (GW - gateway - шлюз)?

2. Всё обсуждение и расчеты выше касались стандартной (биржевой) методики. Даже если у брокера она (внезапно) измененная, тогда к нему и вопросы.
3. Мы в данный момент какую проблему решаем? Могу сказать одно: после начала расчета (корректного!) ГО по биржевой методике у меня еще ни одну заявку не отвергли по лимитам. При использовании функции CalcBuySell() это происходило регулярно.

По-прежнему готов обсуждать примеры и расчеты по стандартной биржевой методике.
 
 
#78
17.02.2016 19:18:38
Да просто Биржа уже достала - постоянно каку-то Хронику внедряет, мне кажется там такие Доумный ИТ отделом, даже вчера расширили дневной клиринг и сообщили об этом только за 10мин, до расширения, просто не знаю такого матерного слова как их назвать.

В профили Алексей Ерпылев, не чего об этом не написано, так что там ещё сомнения. А по поводу CalcBuySell - когда она там выйдет и богу не известно.

В общем, вот написал вариант для LUA, критикуйте.

Код
         local bl = getParamEx(class_code,security,"PRICEMAX").param_value - getParamEx(class_code,security,"CLPRICE").param_value 

               if direction == 'Buy' then

                  go = getParamEx(class_code,security,"BUYDEPO").param_value
                  
                  if price < price_cliring then
                     go = go * math.abs(1 + (price_cliring - price) / (2 *bl))  
                  else
                     go = go * math.abs(1 + (price - price_cliring) / (2 *bl)) 
                  end
               
               else
               
                  go = getParamEx(class_code,security,"SELLDEPO").param_value
                  
                  if price > price_cliring then
                     go = go * math.abs(1 + (price - price_cliring) / (2 *bl))
                  else
                     go = go * math.abs(1 + (price_cliring - price) / (2 *bl))
                  end
                  
               end
 
 
#79
17.02.2016 19:38:16
1. Не видно, чему равна "price_cliring". Если она getParamEx(class_code,security,"CLPRICE").param_value, то правильно.
2. if price < price_cliring ... else ...
Увы, не обработан случай price = price_cliring.
Можно исправить на if price <= price_cliring, будет работать правильно (тогда go = go * 1). То же самое в продаже.
3. math.abs лишнее. При указанных условиях выражения тождественно неотрицательные.
4. Покупка НИЖЕ расчетной цены и продажа ВЫШЕ - будет скидка в ГО. Значит, знак в выражениях в этих случаях "минус": (1 - ...). См. формулы в методике.

А в общем да, именно так.
 
 
#80
17.02.2016 19:41:56
Цитата
SDL написал:
2. if price < price_cliring ... else ...
Увы, не обработан случай price = price_cliring.
Виноват, поспешил. price = price_cliring будет обработан в "else".
 
 
#81
17.02.2016 19:48:05
Так ну вот этот вариант должен сработать, SDL - проверьте пожалуйста со своим исходными данными
Код
local price_cliring = tonumber(getParamEx(class_code,security,"CLPRICE").param_value)
local bl = getParamEx(class_code,security,"PRICEMAX").param_value - getParamEx(class_code,security,"CLPRICE").param_value 
 
if direction == 'B' then

go = getParamEx(class_code,security,"BUYDEPO").param_value

if price < price_cliring then 
go = go * math.abs(1 - (price_cliring - price) / (2 *bl)) -- max  
elsego = go * math.abs(1 + (price - price_cliring) / (2 *bl)) 
end

else

go = getParamEx(class_code,security,"SELLDEPO").param_value

if price > price_cliring then
go = go * math.abs(1 - (price - price_cliring) / (2 *bl))
else
go = go * math.abs(1 + (price_cliring - price) / (2 *bl)) -- max
end

end
 
 
#82
17.02.2016 20:12:29
Цитата
Роман написал:
проверьте пожалуйста со своим исходными данными

Пожалуйста. Сегодняшняя вечерняя сессия. Даю тест кейсы - это мои расчеты. Проверяйте:
ЦенаПокупкаПродажа
698906652,5319957,59
710008642,9117967,21
7360013305,0613305,06
7500015815,4510794,67
7731019957,596652,53
 
 
#83
17.02.2016 20:14:44
Цитата
SDL написал:
TABLE  TD
Ну что за напасть.

Цена    Покупка    Продажа
69890    6652,53    19957,59
71000    8642,91    17967,21
73600    13305,06    13305,06
75000    15815,45    10794,67
77310    19957,59    6652,53
 
 
#84
17.02.2016 20:22:21
SDL, я так не пойму, у вас скрипт те же данные выдаёт, что и мой?

Мне кажеться небольшой недобор есть, бумаг на счете 202 , маржа с планом в плюсе, о он выводит 198.  :what:
 
 
#85
17.02.2016 20:26:35
... Ну и еще оптимизация этого кода:

Код
local price_cliring = tonumber(getParamEx(class_code,security,"CLPRICE").param_value)
local two_bl = getParamEx(class_code,security,"PRICEMAX").param_value - getParamEx(class_code,security,"PRICEMIN").param_value 
 
if direction == 'B' then
  go = getParamEx(class_code,security,"BUYDEPO").param_value
  go = go * (1 + (price - price_cliring) / two_bl) 
else
  go = getParamEx(class_code,security,"SELLDEPO").param_value
  go = go * (1 + (price_cliring - price) / two_bl)
end
 
 
#86
17.02.2016 20:27:55
Цитата
Роман написал:
на счете 202 , маржа с планом в плюсе, о он выводит 198.

Можно подробнее, откуда эти числа?
 
 
#87
17.02.2016 20:28:48
Цитата
SDL написал:
Цитата
Роман   написал:
на счете 202 , маржа с планом в плюсе, о он выводит 198.
Можно подробнее, откуда эти числа?
Боевой счёт.
 
 
#88
17.02.2016 20:30:42
Цитата
SDL написал:
... Ну и еще оптимизация этого кода:
Код
   local  price_cliring  =  tonumber( getParamEx (class_code,security,"CLPRICE").param_value)
 local  two_bl  =   getParamEx (class_code,security,"PRICEMAX").param_value  -   getParamEx (class_code,security,"PRICEMIN").param_value 
 
 if  direction  =  =   'B'   then 
  go  =   getParamEx (class_code,security,"BUYDEPO").param_value
  go  =  go  *  ( 1   +  (price  -  price_cliring) / two_bl) 
 else 
  go  =   getParamEx (class_code,security,"SELLDEPO").param_value
  go  =  go  *  ( 1   +  (price_cliring  -  price) / two_bl)
 end 
  
По цене ниже клиринга, наверное: go  =  go  *  ( 1   -  (price_cliring  -  price) / two_bl) Так теже данные выдаёт, что и у вас?
 
 
#89
17.02.2016 20:34:35
а з.ы. у вас bay и shell
 
 
#90
17.02.2016 20:39:19
Цитата
Роман написал:
SDL, я так не пойму, у вас скрипт те же данные выдаёт, что и мой?

Давайте определимся четко. Мой "скрипт", мозг или что-либо еще не может выдавать те же данные по одной простой причине. У нас разные счета и вообще исходные параметры. Любая программа выдаст одинаковые результаты только при одинаковых входных данных.
Если есть какие-то вопросы по расчетам, большая просьба приводить ВСЕ исходные данные. Тогда будем смотреть и проверять вместе.

Цитата
Роман написал:
Цитата
SDL   написал:
Цитата
Роман   написал:
на счете 202 , маржа с планом в плюсе, о он выводит 198.
Можно подробнее, откуда эти числа?
Боевой счёт.

Всё сказанное выше в полной мере относится и к этому вопросу.
 
 
#91
17.02.2016 20:42:57
Цитата
Роман написал:
По цене ниже клиринга, наверное: go  =  go  *  ( 1   -  (price_cliring  -  price) / two_bl)
Код
if price < price_cliring then 
go = go * math.abs(1 - (price_cliring - price) / (2 *bl)) -- max  
elsego = go * math.abs(1 + (price - price_cliring) / (2 *bl)) 
end
Нет, во всех вариантах цены. Заметьте: 1 - (price_cliring - price) тождественно равно 1 + (price - price_cliring) для любого price
 
 
#92
17.02.2016 20:47:46
Данные раз в секунду обновляются, если по очереди поставите - они приблизительно одинаковые данные выдадут.
просто опять вопрос стоит - как проверить рабочая формула или опять теоретическая.
 
 
#93
17.02.2016 21:03:04
Цитата
Роман написал:
просто опять вопрос стоит - как проверить рабочая формула или опять теоретическая
Цитата
SDL написал:
после начала расчета (корректного!) ГО по биржевой методике у меня еще ни одну заявку не отвергли по лимитам

Посему отвечаю: ГО и макс. количество, рассчитанные по данной теоретической методике, для меня лично являются рабочими.
И я не прячу больше никаких тайных знаний. В случае затруднений смогу помочь разобраться, но только если будут приведены конкретные проблемные цифры, расчеты и даны пояснения.
 
 
#94
17.02.2016 21:17:56
Цитата
Роман написал:
на счете 202 , маржа с планом в плюсе, о он выводит 198
|-------------------------------------|
|____________________| = 202

|-------------------------------------|
|____________________| = 198

Слева от знаков равенства клеточки, которые надо заполнить формулами и числами так, чтобы справа получились указанные значения.
Тогда мы сможем продвинуться в решении. Если так будет понятнее.
 
 
#95
17.02.2016 21:36:03
Цитата
Роман написал:
Данные раз в секунду обновляются
Цитата
Роман написал:
SDL, я так не пойму, у вас скрипт те же данные выдаёт, что и мой?

Сложно догадаться, как вы представляете себе процесс разработки и тестирования программного обеспечения. Наши программы могут быть устроены и работать по совершенно разным принципам, и следовательно, не будут совместимыми по порядку их работы. Где там чего раз в секунду обновляется? Общепризнано, что единственный значимый результат - чистая прибыль по итогам года.
Вы предложили вариант кода для расчета ГО. Он вполне хороший и годный. Я вам дал набор тестовых данных в виде таблички, которые по моему мнению являются правильными, для его проверки. Рассчитайте по ним ГО с помощью своего кода и сравните! Если совпадают, где проблема?
 
 
#96
17.02.2016 23:20:09
Ладно уже голова отказывается считать, пусть на небольшом боевом счёте поработает, посмотрим будет глючить или нет, а так буду ждать оф. функцию. Хорошо что сделали расчёт максимально компактным вот это радует. Благодарю вас SDL за поддержку в этом вопросе!
 
 
#97
18.02.2016 13:56:58
Цитата
SDL написал:
я задал вопрос брокеру

Брокер ответил, что они используют ГО, рассчитанное биржей, со всеми предусмотренными методикой скидками. Хотя они вправе устанавливать свой способ расчета ГО и QUIK позволяет это делать.

Цитата
Роман написал:
на счете 202 , маржа с планом в плюсе, о он выводит 198

Если 202 - это входящий остаток на начало сессии, то для расчета его обеспечения всегда используется цена последнего клиринга, а значит, значение базового ГО. Если вам принудительно не закрывают позиции, это просто означает, что обеспечение достаточное.
Для вычисления макс. количества в текущей сессии, как мы уже хорошо знаем, нужно задать цену заявки. Поэтому с учетом свободного лимита, надбавок/скидок по ГО количество в определенных рамках может получиться любым. Повторю, для подробного анализа нужно знать всю совокупность исходных данных.
 
 
#98
19.02.2016 19:00:53
К сожалению, эта функция тоже цепляет лимиты :(
 
 
#99
19.02.2016 19:50:26
Так что ждём официальный релиз, может и версия квика глючит х.з. ну уже запарился с ней возиться, поставлю меньше маржу и всё. :(
 
 
#100
09.07.2019 11:52:35
Здравствуйте!
Вопрос по функции getBuySellInfoEx.

В версии 7.2.. Quik я определял маржируемость и шортируемость бумаг в скрипте с помощью данной функции и параметров is_long_allowed и is_short_allowed.
Сейчас я поменял версию Quik на 7.23.2.5 и эти параметры перестали работать.
Вот код:

local tbs = getBuySellInfoEx(firm_id, client_code, class_code, sec_code, 0)
local ms = ""
if tbs.is_long_allowed == "1" then ms = "+" else ms = "-" end
if tbs.is_short_allowed == "1" then ms = ms.." +" else ms = ms.." -" end
SetCell(t, i, nc, ms) --заполнение колонки в таблице

Сейчас по всем бумагам показывает отсутствие маржируемости и шортируемости, переменная ms для всех бумаг  "- -"

Эту проблему можно как-то решить?
 
 
Страницы: Пред. 1 2 3 След.
Читают тему
Техническая поддержка
+7 383 219 1606
© 2000–2025,
ARQA Technologies
Наверх