getBuySellInfoEx

Страницы: Пред. 1 2 3 След.
RSS
getBuySellInfoEx
 
Ни разу не сложно привести расчет для второго примера.
Покупка по 70000, ниже расчетной цены (71550).
Имеем:

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

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

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

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

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

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

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

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

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

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

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

В этом документе есть их перечень ("Контракты, предусматривающие данный алгоритм расчёта вариационной маржи").
И, конечно, в спецификации инструментов. Например, по RIxx: "Стоимость минимального шага цены Контракта соответствует 20 % от курса  доллара США по отношению к российскому рублю, установленному в  соответствии с Методикой ..."
 
SDL, ну это понятно - но зачем эти километры кода в скрипте писать и потом следить за их изменениями, Надёжней в параметрах инструмента это указывать и всё, а если функция CalcBuySell будет корректно отражать данные. то в принципе для меня и не актуально будет.
 
Цитата
Роман написал:
в параметрах инструмента это указывать
Если нужно не просто знать, а автоматизировать... Нет, параметра такого не могу назвать.
А зачем? См. выше мой способ расчета корректного ГО. Может подойдет?
 
Цитата
Если нужно не просто знать, а автоматизировать... Нет, параметра такого не могу назвать.
Все подходи и правильно, но конечно всё автоматизировать нужно, с этим ГО на заплатках все работает (хотя новый расчёт ГО ещё в середине прошлого года поменяли), какой смысл одними заплатками менять на другие. Так что решения косяка со стороны КВИК - уже  более чем крайне необходжио!!!  
 
з.ы можно конечно и "валютный шаг" использовать, но там я смотрю там и другие валюты есть, как бы не напороться на ошибку.  
 
SDL.  а вы уверенны что формула с радиусом верна? У меня очень высокое ГО получается, я ещё докупить могу?
 
Цитата
Роман написал:
формула с радиусом верна?

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

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

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

ГО - обеспечение 1 контракта.
Если ГО увеличивается, то количество - ... что?
 
на бирже вообще другое объяснение: http://forum.moex.com/viewtopic.asp?t=30125  :cry: Вообще моразм какой-то, не кто не может указать реально проверенную формулу.
 
SDL, я не вижу примера от биржи, реально, я вижу только куски нарезанных методик взятых с разных документации.
 
На форуме самой биржи, запостил вопрос - надеюсь первоисточник пояснит.
 
SDL,а почему у вас 2L = 75130 - 67970 (это где-то 7000), в той же методички что вы сбрасывали там 2L = базовому ГО, а оно где то 13500?
 
наверное не 2L а просто L
 
Цитата
Роман написал:
на бирже вообще другое объяснение:  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
 
Другой вариант: http://forum.moex.com/viewtopic.asp?t=30919
 
Цитата
Роман написал:
Другой вариант:  http://forum.moex.com/viewtopic.asp?t=30919

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

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

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

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

По-прежнему готов обсуждать примеры и расчеты по стандартной биржевой методике.
 
Да просто Биржа уже достала - постоянно каку-то Хронику внедряет, мне кажется там такие Доумный ИТ отделом, даже вчера расширили дневной клиринг и сообщили об этом только за 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
 
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 - ...). См. формулы в методике.

А в общем да, именно так.
 
Цитата
SDL написал:
2. if price < price_cliring ... else ...
Увы, не обработан случай price = price_cliring.
Виноват, поспешил. price = price_cliring будет обработан в "else".
 
Так ну вот этот вариант должен сработать, 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
 
Цитата
Роман написал:
проверьте пожалуйста со своим исходными данными

Пожалуйста. Сегодняшняя вечерняя сессия. Даю тест кейсы - это мои расчеты. Проверяйте:
ЦенаПокупкаПродажа
698906652,5319957,59
710008642,9117967,21
7360013305,0613305,06
7500015815,4510794,67
7731019957,596652,53
 
Цитата
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
 
SDL, я так не пойму, у вас скрипт те же данные выдаёт, что и мой?

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

Код
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
 
Цитата
Роман написал:
на счете 202 , маржа с планом в плюсе, о он выводит 198.

Можно подробнее, откуда эти числа?
 
Цитата
SDL написал:
Цитата
Роман   написал:
на счете 202 , маржа с планом в плюсе, о он выводит 198.
Можно подробнее, откуда эти числа?
Боевой счёт.
 
Цитата
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) Так теже данные выдаёт, что и у вас?
 
а з.ы. у вас bay и shell
 
Цитата
Роман написал:
SDL, я так не пойму, у вас скрипт те же данные выдаёт, что и мой?

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

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

Всё сказанное выше в полной мере относится и к этому вопросу.
 
Цитата
Роман написал:
По цене ниже клиринга, наверное: 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
 
Данные раз в секунду обновляются, если по очереди поставите - они приблизительно одинаковые данные выдадут.
просто опять вопрос стоит - как проверить рабочая формула или опять теоретическая.
 
Цитата
Роман написал:
просто опять вопрос стоит - как проверить рабочая формула или опять теоретическая
Цитата
SDL написал:
после начала расчета (корректного!) ГО по биржевой методике у меня еще ни одну заявку не отвергли по лимитам

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

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

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

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

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

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

Если 202 - это входящий остаток на начало сессии, то для расчета его обеспечения всегда используется цена последнего клиринга, а значит, значение базового ГО. Если вам принудительно не закрывают позиции, это просто означает, что обеспечение достаточное.
Для вычисления макс. количества в текущей сессии, как мы уже хорошо знаем, нужно задать цену заявки. Поэтому с учетом свободного лимита, надбавок/скидок по ГО количество в определенных рамках может получиться любым. Повторю, для подробного анализа нужно знать всю совокупность исходных данных.
 
К сожалению, эта функция тоже цепляет лимиты :(
 
Так что ждём официальный релиз, может и версия квика глючит х.з. ну уже запарился с ней возиться, поставлю меньше маржу и всё. :(
 
Здравствуйте!
Вопрос по функции 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 След.
Читают тему
Наверх