"... local variables have their scope limited to the block where they are declared. A block is: - the body of a control structure, - the body of a function, - a chunk (the file or string where the variable is declared)."
Таким образом, если весь этот код находится в одном файле, var3 = 8
Вот это неважно. Данный вопрос с таким же успехом легко проясняется:
local var1 = 3 local var2 = 5
function OnInit var3=var1+var2 end
или если угодно:
local var1 = 3 local var2 = 5
function OnInit MyMainProcess(1) end
function MyMainProcess(index) var3=var1+var2 end
Не имеет значения, в каком контексте, в каком потоке и кем вызывается функция.
Ошибки в теле обработчика SetUpdateCallback()
Пользователь
Сообщений: Регистрация: 29.04.2015
14.10.2016 16:01:32
При возникновении программных ошибок в теле обработчика, заданного вызовом SetUpdateCallback(), в поле сообщений окна скриптов не выводится никакой информации, функция просто тихо прекращает свое выполнение. Это не есть правильно. В случае ошибок в других коллбэках, например OnInit(), сообщение выводится.
Заказ всех сделок, Использование CreateDataSource для заказа всех сделок
Проблема, описанная в этой ветке, так за год и не решена.
Версия 7.0.4.10. В скрипте производится заказ всех сделок: CreateDataSource(..., ..., INTERVAL_TICK) SetUpdateCallback(...) Подписка выполняется только в скрипте, таблицы всех сделок в терминале не открываются.
Данные начинают поступать, callback-функция вызывается. При последующих перезапусках скрипта поведение также корректно.
Вывод: ошибка проявляется только при первом запуске скрипта и только при установленном до запуска соединении с сервером. Воспроизводится стабильно. Также установлено, что очистка данных при запуске (info.exe -clear) на описанное поведение не влияет.
Добрый день.
Ошибка будет исправлена в одной из очередных версий программы. Приносим извинения за причиненные неудобства.
Незаметно прошел еще год. Версия 7.4.0.79. Реально ли дождаться исправления ошибки?
Расчет цены клиринга по фьючерсам
Пользователь
Сообщений: Регистрация: 29.04.2015
29.04.2016 12:29:18
Цитата
Николай Камынин написал: цена покупки продажи фьючерса -1 рупь
Нет. Покупаются / продаются не фьючерсы, а базовые активы в рамках срочных контрактов. 1 рупь - это биржевой сбор (комиссия) за заключение / исполнение контрактов. Цены (вообще говоря, котировки) определяются спецификациями контрактов. Например, для фьючерса на индекс РТС - это значение индекса, умноженное на 100.
Расчет цены клиринга по фьючерсам
Пользователь
Сообщений: Регистрация: 29.04.2015
29.04.2016 11:43:11
Цитата
Николай Камынин написал: по фьючерсам есть ГО - т е залог, а не цена покупки продажи
Конечный финансовый результат определяется ценами покупки и продажи. А также стоимостью шага цены и количеством торгуемых контрактов. Всё. ГО к существу заданного вопроса отношения не имеет. ГО необходимо для обеспечения расчетов по сделкам между участниками торгов (фактически, исполнения обязательств в случае убытков). Технически это производится путем блокирования средств в соответствующем размере на счете, что, как следствие, означает ограничение максимального количества торгуемых контрактов. Эти средства блокируются, но остаются на счете и принадлежат клиенту. Размер ГО на финансовый результат сделок не влияет НИКАК.
Расчет цены клиринга по фьючерсам
Пользователь
Сообщений: Регистрация: 29.04.2015
28.04.2016 22:39:32
Цитата
Ivanco написал: доход становится величиной не определенной
Нет, неверно. Доход (а точнее, для рублевых контрактов - в рублях, для валютных - в валюте) зависит только от цен покупки и продажи и никак не от времени удержания позиции, количества и цен проведенных клирингов. Допустим, ваши сделки такие:
Покупка - 91500 Продажа - 93000
Если прошли через клиринг, скажем, по цене 92000, то (формально) происходит следующее:
Это нужно для определения зачисляемой вам вариационной маржи (за первую сессию - 92000 - 91500 = 500, за вторую - 93000 - 92000 = 1000). Очевидно, вне зависимости от цены клиринга финансовый результат такой пары операций тождественно равен нулю:
(клир) Продажа - 92000 (клир) Покупка - 92000
Можно наглядно показать вот так: допустим, конечный финансовый результат 1000 руб. и мы прошли через один клиринг. Тогда этот результат образуется двухкратным (за 2 торговые сессии) зачислением вариационной маржи на ваш счет. При одной цене клиринга он будет, например, состоять из 750 + 250 = 1000, а при другой цене клиринга - 800 + 200 = 1000. Изменятся только промежуточные суммы, конечная останется постоянной и будет определяться только ценами открытия и закрытия позиции.
Но для валютных контрактов, однако, будет неопределенность рублевого результата, она обусловлена курсом валюты, который по установленным правилам вычисляется на каждую клиринговую сессию.
Депозит на демо, Нужно обновить
Пользователь
Сообщений: Регистрация: 29.04.2015
31.03.2016 13:38:43
Цитата
Zoya Skvorcova написал: S.O.S ,Добрый день. Доступ продлён
Все эти ежедневные манипуляции по просьбам трудящихся напоминают никому не нужную игру такую. Раз уже есть робот, который открывает демо-счета, то не доделать бы еще нехитрый личный кабинетик через веб, куда каждый желающий мог заходить и сам спокойно управлять временем жизни своих учебных счетов и лимитами на них. А то ведь весь форум постоянно завален реальными проблемами, на решение которых у разработчика времени порой не хватает.
Исчезновение прерывистых линий
Пользователь
Сообщений: Регистрация: 29.04.2015
22.03.2016 15:01:54
Цитата
Egor Zaytsev написал: Размер архива не должен превышать 10 мб
Почта ушла. Вот подробно, как воспроизводится:
QUIK версия 7.1.2.2, Windows 8.1 русский, для запуска программы установлен режим совместимости с Windows XP SP3.
1. Удалить info.wnd. 2. Запустить info.exe -clear. 3. Меню Создать окно -> График... 4. Выбрать инструмент. Я выбираю RIM6. Откроется окно с графиками цены и объема (по умолчанию). 5. Двойным щелчком по Области 1 открыть диалог редактирования свойств. Содержимое окна:
6. Выделить Область 2:
7. Нажать крестик (удалить):
8. Нажать Добавить. Выбрать индикатор, отметить "Поместить график в новую область":
9. Нажать Добавить:
10. Повторить пп. 8-9:
11. Нажать Применить:
12. Выделить индикатор в Области 2:
13. Нажать Применить. 14. Выделить индикатор в Области 3:
15. Нажать Применить. В этот момент проявляется проблема с "объединением линий" - она всегда в Области 3:
SMTP error fr om remote mail server after MAIL FROM:<...> SIZE=27804888: host mx1.arqatech.com [80.89.133.133]: 552 5.3.4 Message size exceeds fixed lim it
Исчезновение прерывистых линий
Пользователь
Сообщений: Регистрация: 29.04.2015
21.03.2016 15:55:38
Система Windows 8.1
Результат:
Исчезновение прерывистых линий
Пользователь
Сообщений: Регистрация: 29.04.2015
21.03.2016 15:45:25
Цитата
Egor Zaytsev написал: пока определить источник проблемы не удается
1. Выделить этот:
2. Нажать кнопку "Применить".
3. Теперь выделить этот:
4. Нажать кнопку "Применить". Слияние линий появится в нем (область 3).
В крайнем случае повторить еще раз с п. 1.
Для тестов переписывал всё отсюда: Перед запуском терминала удалялся info.wnd, терминал запускался "info.exe -clear". Если так и не воспроизведется, пришлю весь свой каталог.
Исчезновение прерывистых линий
Пользователь
Сообщений: Регистрация: 29.04.2015
18.03.2016 12:59:38
Цитата
Egor Zaytsev написал: прислать свои индикаторы для проверки
Пожалуйста:
Код
Settings =
{
Name = "XXX_Ind",
line =
{
{
Name = "XXX",
Color = RGB(166, 202, 240),
Type = TYPE_LINE,
Width = 1
},
{
Name = "XXXZero",
Color = RGB(255, 255, 0),
Type = TYPE_DASH,
Width = 1
}
}
}
--------------------------------------------------------------------------------
function Init()
return 2
end
--------------------------------------------------------------------------------
function OnCalculate(index)
return 1, 0
end
Действительно, проявляется в IE старых версий. Связано с хостингом. Увидите проблему, если попробуете открыть ссылку на картинку отдельно. Попробуйте в другом браузере.
Исчезновение прерывистых линий
Пользователь
Сообщений: Регистрация: 29.04.2015
17.03.2016 23:33:30
Цитата
Maksim Grudtsyn написал: Описанная проблема была исправлена в версии 7.1.0 терминала QUIK
Очень жаль, что снова и снова ценой новых глюков. Имеем: версия 7.1.2.2. Пользовательский индикатор, несколько линий. Добавляем на график:
Пока всё хорошо. Редактируем какой-нибудь другой индикатор, жмем "Применить" и...
...о, что же это? Две разных линии уже "слились" в одну! Разумеется, со слетанием свойств линий и на графике.
Ошибка "Неверный код клиента" при выставлении заявок, Не проходят заявки выпадает ошибка
Пользователь
Сообщений: Регистрация: 29.04.2015
09.03.2016 20:38:08
См. колонку "Код клиента" таблиц портфеля и лимитов (для фондового рынка). А вообще всё очень просто. Возможные значения представлены в списке выбора поля "Код Клиента" окна ввода заявки. Как правило, для фондового рынка это номер соглашения, для срочного - номер торгового счета. UID - это код терминала, т.е. клиента сервера QUIK. К одним торговым счетам могут иметь доступ разные терминалы с разными кодами. И наоборот.
Вызов окна настроек при запуске индикатора
Пользователь
Сообщений: Регистрация: 29.04.2015
03.03.2016 15:55:40
Цитата
Kolossi написал: Ага, у меня как раз из-под wine (Mac)
Программа поддерживается только под Windows. В данном случае можно только попросить разобраться, может там дело в ерунде какой.
В таком случае я делаю нужные мне настройки в Windows, а потом копирую готовый info.wnd.
Вызов окна настроек при запуске индикатора
Пользователь
Сообщений: Регистрация: 29.04.2015
03.03.2016 15:37:35
Цитата
Kolossi написал: отсутствует вкладка "Общие". Имеются только вкладки "Дополнительно" и "Уровни".
Ага, есть такая проблема. В Linux из-под WINE у меня проявляется. И в 6-й версии так же. Наверно, эта вкладка написана очень нестандартно.
Ошибка в создании транзакции, ОШИБКА 159
Пользователь
Сообщений: Регистрация: 29.04.2015
25.02.2016 20:27:22
Варианты: 1. Попробуйте совсем убрать TYPE = L. Заявки лимитные по умолчанию. 2. Задать цену с 2-мя знаками вместо одного ("143.70"). 2. Я ввел аналогичную заявку в карман транзакций и сохранил в файл. Вот что получилось:
Код
TRANS_ID=1;
CLASSCODE=TQBR;
ACTION=Ввод заявки;
Торговый счет=L01+00000F00;
К/П=Купля;
Тип=Лимитная;
Тип по цене=По разным ценам;
Тип по остатку=Поставить в очередь;
Тип ввода значения цены=По цене;
Назначение заявки=По умолчанию;
Тип события активации заявки=Обычная заявка;
Режим=TQBR;
Инструмент=GAZP;
Цена=143.70;
Лоты=1;
Примечание=;
Объем заявки=0.00;
Код внешнего пользователя=;
Время активации=;
Доп. инфо=;
Интересно, что такое параметр "Режим" (равен "CLASSCODE")? Может, проблема в его отсутствии?
Попробуйте сделать также и отправить транзакцию из кармана (предварительно сохранив в файл). Если уйдет нормально: в скрипте составьте точно такую же (именно в этом формате со всеми этими параметрами). Далее, исключая один параметр за другим (необязательные), можно будет понять, в каком из них проблема.
Ничего тут непонятного нет. Это числовой номер заявки в торговой системе.
Цитата
В В написал: как переделать ["ORDER_KEY"] и/или что-то ещё, чтобы работало?
Не надо ничего переделывать. Заявка снимаются по её номеру. После отправки отправки транзакции "NEW_ORDER" в случае успеха получаем:
Код
transReply=
{
["status"]=3
["trans_id"]=<...>
["result_msg"]="Заявка, с биржевым номером 3188566693, успешно зарегистрирована."
["order_num"]=3188566693
......
}
Запоминаем "order_num" и используем. И еще в любой момент можем его получить чтением таблицы заявок - getNumberOf() / getItem().
Ошибка в создании транзакции, ОШИБКА 159
Пользователь
Сообщений: Регистрация: 29.04.2015
25.02.2016 00:40:02
Цитата
Владимир Киселев написал: ["COMMENT"] = "Покупка бумаг скриптом"
У транзакций нет поля "COMMENT". Это только для импорта из .tri-файла для групповых операций. Правильно так:
Странно: в ответе: [9456] OnTransReply-quantity 24 А в транзакции - 1. Есть подозрение, что это ответ на другую транзакцию, которая действительно с ошибочными параметрами. Попробуйте выводить в лог все отправляемые транзакции с их фактическими параметрами, а то по коду это сложно понять. И потом спаривать их по trans_id и уже сравнивать.
Брокер ответил, что они используют ГО, рассчитанное биржей, со всеми предусмотренными методикой скидками. Хотя они вправе устанавливать свой способ расчета ГО и QUIK позволяет это делать.
Цитата
Роман написал: на счете 202 , маржа с планом в плюсе, о он выводит 198
Если 202 - это входящий остаток на начало сессии, то для расчета его обеспечения всегда используется цена последнего клиринга, а значит, значение базового ГО. Если вам принудительно не закрывают позиции, это просто означает, что обеспечение достаточное. Для вычисления макс. количества в текущей сессии, как мы уже хорошо знаем, нужно задать цену заявки. Поэтому с учетом свободного лимита, надбавок/скидок по ГО количество в определенных рамках может получиться любым. Повторю, для подробного анализа нужно знать всю совокупность исходных данных.
Роман написал: SDL, я так не пойму, у вас скрипт те же данные выдаёт, что и мой?
Сложно догадаться, как вы представляете себе процесс разработки и тестирования программного обеспечения. Наши программы могут быть устроены и работать по совершенно разным принципам, и следовательно, не будут совместимыми по порядку их работы. Где там чего раз в секунду обновляется? Общепризнано, что единственный значимый результат - чистая прибыль по итогам года. Вы предложили вариант кода для расчета ГО. Он вполне хороший и годный. Я вам дал набор тестовых данных в виде таблички, которые по моему мнению являются правильными, для его проверки. Рассчитайте по ним ГО с помощью своего кода и сравните! Если совпадают, где проблема?
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
17.02.2016 21:17:56
Цитата
Роман написал: на счете 202 , маржа с планом в плюсе, о он выводит 198
Слева от знаков равенства клеточки, которые надо заполнить формулами и числами так, чтобы справа получились указанные значения. Тогда мы сможем продвинуться в решении. Если так будет понятнее.
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
17.02.2016 21:03:04
Цитата
Роман написал: просто опять вопрос стоит - как проверить рабочая формула или опять теоретическая
Цитата
SDL написал: после начала расчета (корректного!) ГО по биржевой методике у меня еще ни одну заявку не отвергли по лимитам
Посему отвечаю: ГО и макс. количество, рассчитанные по данной теоретической методике, для меня лично являются рабочими. И я не прячу больше никаких тайных знаний. В случае затруднений смогу помочь разобраться, но только если будут приведены конкретные проблемные цифры, расчеты и даны пояснения.
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
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
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
17.02.2016 20:39:19
Цитата
Роман написал: SDL, я так не пойму, у вас скрипт те же данные выдаёт, что и мой?
Давайте определимся четко. Мой "скрипт", мозг или что-либо еще не может выдавать те же данные по одной простой причине. У нас разные счета и вообще исходные параметры. Любая программа выдаст одинаковые результаты только при одинаковых входных данных. Если есть какие-то вопросы по расчетам, большая просьба приводить ВСЕ исходные данные. Тогда будем смотреть и проверять вместе.
Роман написал: на счете 202 , маржа с планом в плюсе, о он выводит 198.
Можно подробнее, откуда эти числа?
Боевой счёт.
Всё сказанное выше в полной мере относится и к этому вопросу.
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
17.02.2016 20:27:55
Цитата
Роман написал: на счете 202 , маржа с планом в плюсе, о он выводит 198.
Можно подробнее, откуда эти числа?
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
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
Роман написал: проверьте пожалуйста со своим исходными данными
Пожалуйста. Сегодняшняя вечерняя сессия. Даю тест кейсы - это мои расчеты. Проверяйте:
Цена
Покупка
Продажа
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
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
17.02.2016 19:41:56
Цитата
SDL написал: 2. if price < price_cliring ... else ... Увы, не обработан случай price = price_cliring.
Виноват, поспешил. price = price_cliring будет обработан в "else".
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
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 - ...). См. формулы в методике.
А в общем да, именно так.
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
17.02.2016 19:03:04
Цитата
Роман написал: там всплывают всё новые и новые подробности!
Прочитал. Да, интересный поворот, ничего не скажешь. А "Алексей Ерпылев" там сотрудник биржи? 1. Ок, я задал вопрос брокеру, самому интересно стало. Но. Следует отметить:
["result_msg"]="Ошибка создания заявки. [GW][332] \"Нехватка средств по лимитам клиента.\"." Это кто отлуп дает - брокер или всё-таки биржа (GW - gateway - шлюз)?
2. Всё обсуждение и расчеты выше касались стандартной (биржевой) методики. Даже если у брокера она (внезапно) измененная, тогда к нему и вопросы. 3. Мы в данный момент какую проблему решаем? Могу сказать одно: после начала расчета (корректного!) ГО по биржевой методике у меня еще ни одну заявку не отвергли по лимитам. При использовании функции CalcBuySell() это происходило регулярно.
По-прежнему готов обсуждать примеры и расчеты по стандартной биржевой методике.
Правильный расчет, строго по этой методике. В чем он другой, я не могу понять? Можно конкретно сравнить и показать?
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
17.02.2016 10:34:04
Цитата
Роман написал: на бирже вообще другое объяснение: Вообще моразм какой-то, не кто не может указать реально проверенную формулу.
Несправедливое утверждение. Все примеры расчетов, что я приводил, в точности соответствуют объяснениям по этой ссылке. Если есть сомнения, готов разобрать конкретный пример, приводите данные.
Цитата
Роман написал: , я не вижу примера от биржи, реально, я вижу только куски нарезанных методик взятых с разных документации.
Методика изложена в нескольких документах, это правда. Но они не противоречат, а дополняют друг друга. Все здесь, в одном месте:
Цитата
Роман написал: ,а почему у вас 2L = 75130 - 67970 (это где-то 7000), в той же методички что вы сбрасывали там 2L = базовому ГО, а оно где то 13500?
Потому что 2L - это ГО в пунктах, чтобы получить рубли, надо применить формулу ГО = ГО_в_пунктах * (MisStepPrice / MinStep) * (1 + R / 100)
... которая приведена, в частности, и по указанной ссылке на форуме биржи.
1. Методику нам дала биржа. Явных противоречий там вроде нет. 2. Если есть сомнения, легко посчитать самому и сравнить. Для цены, равной расчетной (посл. клиринга), должно получиться ГО, транслируемое в параметрах контракта.
Цитата
Роман написал: У меня очень высокое ГО получается, я ещё докупить могу?
Макс. кол-во = Денежный лимит / ГО
ГО - обеспечение 1 контракта. Если ГО увеличивается, то количество - ... что?
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
16.02.2016 19:40:50
Цитата
Роман написал: в параметрах инструмента это указывать
Если нужно не просто знать, а автоматизировать... Нет, параметра такого не могу назвать. А зачем? См. выше мой способ расчета корректного ГО. Может подойдет?
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
16.02.2016 19:26:54
Цитата
Роман написал: с радиусом ещё и проблема в том, что в свойствах инструментов нет указаний, нужно ли его применить к данному инструменту или нет
В этом документе есть их перечень ("Контракты, предусматривающие данный алгоритм расчёта вариационной маржи"). И, конечно, в спецификации инструментов. Например, по RIxx: "Стоимость минимального шага цены Контракта соответствует 20 % от курса доллара США по отношению к российскому рублю, установленному в соответствии с ..."
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
16.02.2016 19:07:44
Цитата
Sergey Gorokhov написал: К сожалению ответ сотрудника неверный Отсутствие учета радиуса курса валют относится конечно же к срочному рынку.
Это радует, что наконец с этим вопросом разобрались. По поводу текущего положения нужно сказать следующее. В данном случае такая "частичная" реализация алгоритма ГО (во всяком случае на инструментах, привязанных к валютам) - всё равно, что отсутствие таковой полностью. Некорректно рассчитанное макс. количество контрактов может (но конечно, не во всех случаях) привести к превышению лимитов. И какой тогда смысл в этом расчете? Это всё равно, что залить полный бак бензина, но не залить масло: автомобиль одно не поедет.
По вопросу относительно функции CalcBuySell. Если я правильно понимаю, она должна возвращать значение, полностью идентичное рассчитываемому в окне ввода заявки. Давайте исходить из того, что лимиты придуманы биржей не для того, чтобы их нарушать. Поэтому чудес быть не должно. У меня есть следующее предположение, как это можно проверить. ГО с учетом радиуса курса больше, но ненамного - процентов на 15-20. Попробуйте ввести заявку, когда денежный лимит на счете в точности равен (или кратен) размеру ГО, рассчитанному терминалом. Идея понятна? Вполне возможно, лимита хватало, поэтому проблема с превышением не воспроизводилась.
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
16.02.2016 18:35:22
Теперь немного конструктива. Для всех, кому актуально. Для получения правильного размера ГО в текущей ситуации есть недорогой "костыль". Можно использовать значение ГО в рублях, транслируемое в параметрах инструмента. Оно рассчитано биржей правильно, с учетом радиуса курса. Только его надо скорректировать, потому что оно "базовое", т.е. соответствует ГО в пунrтах = 2L и, соответственно, заявкам по расчетной цене (цене клиринга).
Например, у нас покупка по цене ниже лимита. Берем ГО в рублях, делим на 2L и умножаем на 2L – (РЦ – Ц), формула из методики. Получаем правильное ГО.
В реализованном алгоритме расчета ГО для клиентского места QUIK версии 7.0 пока не поддержан учет радиуса курса валют. Это приводит к расхождению ГО по сравнению с биржевым. Постараемся доработать функционал в одной из следующих версий.
Данная проблема относится к Валютному рынку и действительно имеет место быть. Мы работаем над ее устранением. Показатели же по Срочному и Фондовому рынкам рекомендуем проверять на актуальной версии терминала.
Цитата
Sergey Gorokhov написал: Что касается учета радиуса курса валют, то на данный момент этот функционал пока еще не реализован.
Честно говоря, больше не хочется ходить по кругу.
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
16.02.2016 18:10:31
Ни разу не сложно привести расчет для второго примера. Покупка по 70000, ниже расчетной цены (71550). Имеем:
... что без проблем соответствует значению ГО в примере (для 1000 контрактов). И конечно, снова без учета радиуса валютного курса.
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
16.02.2016 17:57:02
Цитата
Sergey Gorokhov написал: Нет не подтверждаю. Не воспроизводится.
Потрясающе. Теперь вы против своих собственных скринов окна заявки не будете возражать? Надеюсь, вы используете актуальную версию терминала.
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
16.02.2016 17:45:50
Цитата
Роман написал: так вопрос то не в том, что она меняется, а в том что не правильно меняется именно в цифрах!
Это потому, что нас слушают, но не слышат. Пример на демо-системе, ок, там то же самое. Возьмем первый скрин. Цена 75130, по верхнему лимиту. Введено 1000 контрактов, давайте для простоты и наглядности брать 1 контракт, ГО тогда будет 16588.68
Вовсе не исключаю каких-либо ещё проблем с расчетом ГО при определенных условиях. Однако. Приведенные примеры демонстрируют наличие проблем именно при указанных условиях. И неплохо бы изжить для начала их.
getBuySellInfoEx
Пользователь
Сообщений: Регистрация: 29.04.2015
12.02.2016 15:07:35
Цитата
Stanislav Tvorogov написал: Показатели же по Срочному и Фондовому рынкам рекомендуем проверять на актуальной версии терминала
Пожалуйста, вот самая свежая проверка: 12.02.2016, 14:50. RIH6, данные промклиринга 12.02.2016 от 14:04:
Стоимость шага цены (MinStepPrice) - 15,89082 Нижний лимит (Pmin) - 64 470 Верхний лимит (Pmax) - 71 890 Расчетная цена последнего клиринга - 68 180 Базовое ГО - 13 913,53