"... 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
При возникновении программных ошибок в теле обработчика, заданного вызовом SetUpdateCallback(), в поле сообщений окна скриптов не выводится никакой информации, функция просто тихо прекращает свое выполнение. Это не есть правильно. В случае ошибок в других коллбэках, например OnInit(), сообщение выводится.
Проблема, описанная в этой ветке, так за год и не решена.
Версия 7.0.4.10. В скрипте производится заказ всех сделок: CreateDataSource(..., ..., INTERVAL_TICK) SetUpdateCallback(...) Подписка выполняется только в скрипте, таблицы всех сделок в терминале не открываются.
Данные начинают поступать, callback-функция вызывается. При последующих перезапусках скрипта поведение также корректно.
Вывод: ошибка проявляется только при первом запуске скрипта и только при установленном до запуска соединении с сервером. Воспроизводится стабильно. Также установлено, что очистка данных при запуске (info.exe -clear) на описанное поведение не влияет.
Добрый день.
Ошибка будет исправлена в одной из очередных версий программы. Приносим извинения за причиненные неудобства.
Незаметно прошел еще год. Версия 7.4.0.79. Реально ли дождаться исправления ошибки?
Николай Камынин написал: цена покупки продажи фьючерса -1 рупь
Нет. Покупаются / продаются не фьючерсы, а базовые активы в рамках срочных контрактов. 1 рупь - это биржевой сбор (комиссия) за заключение / исполнение контрактов. Цены (вообще говоря, котировки) определяются спецификациями контрактов. Например, для фьючерса на индекс РТС - это значение индекса, умноженное на 100.
Николай Камынин написал: по фьючерсам есть ГО - т е залог, а не цена покупки продажи
Конечный финансовый результат определяется ценами покупки и продажи. А также стоимостью шага цены и количеством торгуемых контрактов. Всё. ГО к существу заданного вопроса отношения не имеет. ГО необходимо для обеспечения расчетов по сделкам между участниками торгов (фактически, исполнения обязательств в случае убытков). Технически это производится путем блокирования средств в соответствующем размере на счете, что, как следствие, означает ограничение максимального количества торгуемых контрактов. Эти средства блокируются, но остаются на счете и принадлежат клиенту. Размер ГО на финансовый результат сделок не влияет НИКАК.
Ivanco написал: доход становится величиной не определенной
Нет, неверно. Доход (а точнее, для рублевых контрактов - в рублях, для валютных - в валюте) зависит только от цен покупки и продажи и никак не от времени удержания позиции, количества и цен проведенных клирингов. Допустим, ваши сделки такие:
Покупка - 91500 Продажа - 93000
Если прошли через клиринг, скажем, по цене 92000, то (формально) происходит следующее:
Это нужно для определения зачисляемой вам вариационной маржи (за первую сессию - 92000 - 91500 = 500, за вторую - 93000 - 92000 = 1000). Очевидно, вне зависимости от цены клиринга финансовый результат такой пары операций тождественно равен нулю:
(клир) Продажа - 92000 (клир) Покупка - 92000
Можно наглядно показать вот так: допустим, конечный финансовый результат 1000 руб. и мы прошли через один клиринг. Тогда этот результат образуется двухкратным (за 2 торговые сессии) зачислением вариационной маржи на ваш счет. При одной цене клиринга он будет, например, состоять из 750 + 250 = 1000, а при другой цене клиринга - 800 + 200 = 1000. Изменятся только промежуточные суммы, конечная останется постоянной и будет определяться только ценами открытия и закрытия позиции.
Но для валютных контрактов, однако, будет неопределенность рублевого результата, она обусловлена курсом валюты, который по установленным правилам вычисляется на каждую клиринговую сессию.
Zoya Skvorcova написал: S.O.S ,Добрый день. Доступ продлён
Все эти ежедневные манипуляции по просьбам трудящихся напоминают никому не нужную игру такую. Раз уже есть робот, который открывает демо-счета, то не доделать бы еще нехитрый личный кабинетик через веб, куда каждый желающий мог заходить и сам спокойно управлять временем жизни своих учебных счетов и лимитами на них. А то ведь весь форум постоянно завален реальными проблемами, на решение которых у разработчика времени порой не хватает.
quiksupport@arqatech.com 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
Egor Zaytsev написал: пока определить источник проблемы не удается
1. Выделить этот:
2. Нажать кнопку "Применить".
3. Теперь выделить этот:
4. Нажать кнопку "Применить". Слияние линий появится в нем (область 3).
В крайнем случае повторить еще раз с п. 1.
Для тестов переписывал всё отсюда: ftp://ftp.quik.ru/public/updates/7.1/quik_7.1.2_upd.zip Перед запуском терминала удалялся info.wnd, терминал запускался "info.exe -clear". Если так и не воспроизведется, пришлю весь свой каталог.
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 старых версий. Связано с хостингом. Увидите проблему, если попробуете открыть ссылку на картинку отдельно. Попробуйте в другом браузере.
См. колонку "Код клиента" таблиц портфеля и лимитов (для фондового рынка). А вообще всё очень просто. Возможные значения представлены в списке выбора поля "Код Клиента" окна ввода заявки. Как правило, для фондового рынка это номер соглашения, для срочного - номер торгового счета. UID - это код терминала, т.е. клиента сервера QUIK. К одним торговым счетам могут иметь доступ разные терминалы с разными кодами. И наоборот.
Варианты: 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().
Странно: в ответе: [9456] OnTransReply-quantity 24 А в транзакции - 1. Есть подозрение, что это ответ на другую транзакцию, которая действительно с ошибочными параметрами. Попробуйте выводить в лог все отправляемые транзакции с их фактическими параметрами, а то по коду это сложно понять. И потом спаривать их по trans_id и уже сравнивать.
Брокер ответил, что они используют ГО, рассчитанное биржей, со всеми предусмотренными методикой скидками. Хотя они вправе устанавливать свой способ расчета ГО и QUIK позволяет это делать.
Цитата
Роман написал: на счете 202 , маржа с планом в плюсе, о он выводит 198
Если 202 - это входящий остаток на начало сессии, то для расчета его обеспечения всегда используется цена последнего клиринга, а значит, значение базового ГО. Если вам принудительно не закрывают позиции, это просто означает, что обеспечение достаточное. Для вычисления макс. количества в текущей сессии, как мы уже хорошо знаем, нужно задать цену заявки. Поэтому с учетом свободного лимита, надбавок/скидок по ГО количество в определенных рамках может получиться любым. Повторю, для подробного анализа нужно знать всю совокупность исходных данных.
Роман написал: SDL, я так не пойму, у вас скрипт те же данные выдаёт, что и мой?
Сложно догадаться, как вы представляете себе процесс разработки и тестирования программного обеспечения. Наши программы могут быть устроены и работать по совершенно разным принципам, и следовательно, не будут совместимыми по порядку их работы. Где там чего раз в секунду обновляется? Общепризнано, что единственный значимый результат - чистая прибыль по итогам года. Вы предложили вариант кода для расчета ГО. Он вполне хороший и годный. Я вам дал набор тестовых данных в виде таблички, которые по моему мнению являются правильными, для его проверки. Рассчитайте по ним ГО с помощью своего кода и сравните! Если совпадают, где проблема?
Слева от знаков равенства клеточки, которые надо заполнить формулами и числами так, чтобы справа получились указанные значения. Тогда мы сможем продвинуться в решении. Если так будет понятнее.
Роман написал: просто опять вопрос стоит - как проверить рабочая формула или опять теоретическая
Цитата
SDL написал: после начала расчета (корректного!) ГО по биржевой методике у меня еще ни одну заявку не отвергли по лимитам
Посему отвечаю: ГО и макс. количество, рассчитанные по данной теоретической методике, для меня лично являются рабочими. И я не прячу больше никаких тайных знаний. В случае затруднений смогу помочь разобраться, но только если будут приведены конкретные проблемные цифры, расчеты и даны пояснения.
Роман написал: По цене ниже клиринга, наверное: 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, я так не пойму, у вас скрипт те же данные выдаёт, что и мой?
Давайте определимся четко. Мой "скрипт", мозг или что-либо еще не может выдавать те же данные по одной простой причине. У нас разные счета и вообще исходные параметры. Любая программа выдаст одинаковые результаты только при одинаковых входных данных. Если есть какие-то вопросы по расчетам, большая просьба приводить ВСЕ исходные данные. Тогда будем смотреть и проверять вместе.
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
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 - ...). См. формулы в методике.
Роман написал: там всплывают всё новые и новые подробности!
Прочитал. Да, интересный поворот, ничего не скажешь. А "Алексей Ерпылев" там сотрудник биржи? 1. Ок, я задал вопрос брокеру, самому интересно стало. Но. Следует отметить:
["result_msg"]="Ошибка создания заявки. [GW][332] \"Нехватка средств по лимитам клиента.\"." Это кто отлуп дает - брокер или всё-таки биржа (GW - gateway - шлюз)?
2. Всё обсуждение и расчеты выше касались стандартной (биржевой) методики. Даже если у брокера она (внезапно) измененная, тогда к нему и вопросы. 3. Мы в данный момент какую проблему решаем? Могу сказать одно: после начала расчета (корректного!) ГО по биржевой методике у меня еще ни одну заявку не отвергли по лимитам. При использовании функции CalcBuySell() это происходило регулярно.
По-прежнему готов обсуждать примеры и расчеты по стандартной биржевой методике.
Несправедливое утверждение. Все примеры расчетов, что я приводил, в точности соответствуют объяснениям по этой ссылке. Если есть сомнения, готов разобрать конкретный пример, приводите данные.
Цитата
Роман написал: SDL , я не вижу примера от биржи, реально, я вижу только куски нарезанных методик взятых с разных документации.
Методика изложена в нескольких документах, это правда. Но они не противоречат, а дополняют друг друга. Все здесь, в одном месте: http://moex.com/a186
Цитата
Роман написал: SDL ,а почему у вас 2L = 75130 - 67970 (это где-то 7000), в той же методички что вы сбрасывали там 2L = базовому ГО, а оно где то 13500?
Потому что 2L - это ГО в пунктах, чтобы получить рубли, надо применить формулу ГО = ГО_в_пунктах * (MisStepPrice / MinStep) * (1 + R / 100)
... которая приведена, в частности, и по указанной ссылке на форуме биржи.
1. Методику нам дала биржа. Явных противоречий там вроде нет. 2. Если есть сомнения, легко посчитать самому и сравнить. Для цены, равной расчетной (посл. клиринга), должно получиться ГО, транслируемое в параметрах контракта.
Цитата
Роман написал: У меня очень высокое ГО получается, я ещё докупить могу?
Макс. кол-во = Денежный лимит / ГО
ГО - обеспечение 1 контракта. Если ГО увеличивается, то количество - ... что?
Роман написал: в параметрах инструмента это указывать
Если нужно не просто знать, а автоматизировать... Нет, параметра такого не могу назвать. А зачем? См. выше мой способ расчета корректного ГО. Может подойдет?
В этом документе есть их перечень ("Контракты, предусматривающие данный алгоритм расчёта вариационной маржи"). И, конечно, в спецификации инструментов. Например, по RIxx: "Стоимость минимального шага цены Контракта соответствует 20 % от курса доллара США по отношению к российскому рублю, установленному в соответствии с Методикой ..."
Sergey Gorokhov написал: К сожалению ответ сотрудника неверный Отсутствие учета радиуса курса валют относится конечно же к срочному рынку.
Это радует, что наконец с этим вопросом разобрались. По поводу текущего положения нужно сказать следующее. В данном случае такая "частичная" реализация алгоритма ГО (во всяком случае на инструментах, привязанных к валютам) - всё равно, что отсутствие таковой полностью. Некорректно рассчитанное макс. количество контрактов может (но конечно, не во всех случаях) привести к превышению лимитов. И какой тогда смысл в этом расчете? Это всё равно, что залить полный бак бензина, но не залить масло: автомобиль одно не поедет.
По вопросу относительно функции CalcBuySell. Если я правильно понимаю, она должна возвращать значение, полностью идентичное рассчитываемому в окне ввода заявки. Давайте исходить из того, что лимиты придуманы биржей не для того, чтобы их нарушать. Поэтому чудес быть не должно. У меня есть следующее предположение, как это можно проверить. ГО с учетом радиуса курса больше, но ненамного - процентов на 15-20. Попробуйте ввести заявку, когда денежный лимит на счете в точности равен (или кратен) размеру ГО, рассчитанному терминалом. Идея понятна? Вполне возможно, лимита хватало, поэтому проблема с превышением не воспроизводилась.
Теперь немного конструктива. Для всех, кому актуально. Для получения правильного размера ГО в текущей ситуации есть недорогой "костыль". Можно использовать значение ГО в рублях, транслируемое в параметрах инструмента. Оно рассчитано биржей правильно, с учетом радиуса курса. Только его надо скорректировать, потому что оно "базовое", т.е. соответствует ГО в пунrтах = 2L и, соответственно, заявкам по расчетной цене (цене клиринга).
Например, у нас покупка по цене ниже лимита. Берем ГО в рублях, делим на 2L и умножаем на 2L – (РЦ – Ц), формула из методики. Получаем правильное ГО.
В реализованном алгоритме расчета ГО для клиентского места QUIK версии 7.0 пока не поддержан учет радиуса курса валют. Это приводит к расхождению ГО по сравнению с биржевым. Постараемся доработать функционал в одной из следующих версий.
Данная проблема относится к Валютному рынку и действительно имеет место быть. Мы работаем над ее устранением. Показатели же по Срочному и Фондовому рынкам рекомендуем проверять на актуальной версии терминала.
Цитата
Sergey Gorokhov написал: Что касается учета радиуса курса валют, то на данный момент этот функционал пока еще не реализован.
Роман написал: так вопрос то не в том, что она меняется, а в том что не правильно меняется именно в цифрах!
Это потому, что нас слушают, но не слышат. Пример на демо-системе, ок, там то же самое. Возьмем первый скрин. Цена 75130, по верхнему лимиту. Введено 1000 контрактов, давайте для простоты и наглядности брать 1 контракт, ГО тогда будет 16588.68
Вовсе не исключаю каких-либо ещё проблем с расчетом ГО при определенных условиях. Однако. Приведенные примеры демонстрируют наличие проблем именно при указанных условиях. И неплохо бы изжить для начала их.