SDL (Все сообщения пользователя)

Выбрать дату в календареВыбрать дату в календаре

Страницы: Пред. 1 2 3 След.
Видимость переменных в калбэк функциях
 
Цитата
Владимир Б****ов написал:

Вопрос: чему будет равняться var3?

"... 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()
 
При возникновении программных ошибок в теле обработчика, заданного вызовом SetUpdateCallback(), в поле сообщений окна скриптов не выводится никакой информации, функция просто тихо прекращает свое выполнение. Это не есть правильно. В случае ошибок в других коллбэках, например OnInit(), сообщение выводится.
Заказ всех сделок, Использование CreateDataSource для заказа всех сделок
 
Цитата
Alexey Ivannikov написал:
Цитата
SDL   пишет:
Цитата
Серж пишет:
Продолжение этой темы:  http://forum-archive.quik.ru/forum/lua/125655/125655/  
Проблема, описанная в этой ветке, так за год и не решена.

Версия 7.0.4.10.
В скрипте производится заказ всех сделок:
CreateDataSource(..., ..., INTERVAL_TICK)
SetUpdateCallback(...)
Подписка выполняется только в скрипте, таблицы всех сделок в терминале не открываются.

Вариант А).
1. Запускаем терминал.
2. Запускаем скрипт.
3. Устанавливаем соединение.

Заказанные данные поступают, callback-функция вызывается.

Вариант Б).
1. Запускаем терминал.
2. Устанавливаем соединение.
3. Запускаем скрипт.

Callback-функция не вызывается.

Далее:
4. Останавливаем скрипт.
5. Запускаем скрипт.

Данные начинают поступать, callback-функция вызывается.
При последующих перезапусках скрипта поведение также корректно.

Вывод: ошибка проявляется только при первом запуске скрипта и только при установленном до запуска соединении с сервером.
Воспроизводится стабильно. Также установлено, что очистка данных при запуске (info.exe -clear) на описанное поведение не влияет.
Добрый день.

Ошибка будет исправлена в одной из очередных версий программы.
Приносим извинения за причиненные неудобства.

Незаметно прошел еще год. Версия 7.4.0.79. Реально ли дождаться исправления ошибки?
Расчет цены клиринга по фьючерсам
 
Цитата
Николай Камынин написал:
цена покупки продажи фьючерса -1 рупь

Нет. Покупаются / продаются не фьючерсы, а базовые активы в рамках  срочных контрактов. 1 рупь - это биржевой сбор (комиссия) за заключение /  исполнение контрактов. Цены (вообще говоря, котировки) определяются  спецификациями контрактов. Например, для фьючерса на индекс РТС - это  значение индекса, умноженное на 100.
Расчет цены клиринга по фьючерсам
 
Цитата
Николай Камынин написал:
по фьючерсам есть ГО - т е залог,
а не цена покупки продажи
Конечный финансовый результат определяется ценами покупки и продажи. А также стоимостью шага цены и количеством торгуемых контрактов. Всё. ГО к существу заданного вопроса отношения не имеет. ГО необходимо для обеспечения расчетов по сделкам между участниками торгов (фактически, исполнения обязательств в случае убытков). Технически это производится путем блокирования средств в соответствующем размере на счете, что, как следствие, означает ограничение максимального количества торгуемых контрактов. Эти средства блокируются, но остаются на счете и принадлежат клиенту. Размер ГО на финансовый результат сделок не влияет НИКАК.
Расчет цены клиринга по фьючерсам
 
Цитата
Ivanco написал:
доход становится величиной не определенной

Нет, неверно. Доход (а точнее, для рублевых контрактов - в рублях, для валютных - в валюте) зависит только от цен покупки и продажи и никак не от времени удержания позиции, количества и цен проведенных клирингов.
Допустим, ваши сделки такие:

Покупка - 91500
Продажа - 93000

Если прошли через клиринг, скажем, по цене 92000, то (формально) происходит следующее:

Покупка - 91500
(клир) Продажа - 92000
(клир) Покупка - 92000
Продажа - 93000

Это нужно для определения зачисляемой вам вариационной маржи (за первую сессию - 92000 - 91500 = 500, за вторую - 93000 - 92000 = 1000).
Очевидно, вне зависимости от цены клиринга финансовый результат такой пары операций тождественно равен нулю:

(клир) Продажа - 92000
(клир) Покупка - 92000

Можно наглядно показать вот так: допустим, конечный финансовый результат 1000 руб. и мы прошли через один клиринг.
Тогда этот результат образуется двухкратным (за 2 торговые сессии) зачислением вариационной маржи на ваш счет. При одной цене клиринга он будет, например, состоять из 750 + 250 = 1000, а при другой цене клиринга  - 800 + 200 = 1000. Изменятся только промежуточные суммы, конечная останется постоянной и будет определяться только ценами открытия и закрытия позиции.

Но для валютных контрактов, однако, будет неопределенность рублевого результата, она обусловлена курсом валюты, который по установленным правилам вычисляется на каждую клиринговую сессию.
Депозит на демо, Нужно обновить
 
Цитата
Zoya Skvorcova написал:
S.O.S  ,Добрый день.
Доступ продлён

Все эти ежедневные манипуляции по просьбам трудящихся напоминают никому не нужную игру такую. Раз уже есть робот, который открывает демо-счета, то не доделать бы еще нехитрый личный кабинетик через веб, куда каждый желающий мог заходить и сам спокойно управлять временем жизни своих учебных счетов и лимитами на них. А то ведь весь форум постоянно завален реальными проблемами, на решение которых у разработчика времени порой не хватает.
Исчезновение прерывистых линий
 
Цитата
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:



У графика в Области 2 при этом полный порядок:

Исчезновение прерывистых линий
 
Цитата
Egor Zaytsev написал:
Пришлите архив терминала

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
Исчезновение прерывистых линий
 
Система Windows 8.1

Результат:
Исчезновение прерывистых линий
 
Цитата
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


Цитата
Egor Zaytsev написал:
проблем не наблюдаем

А вот так вот сделайте:

Исчезновение прерывистых линий
 
Цитата
swerg написал:
как-то картинок-то не видно

Действительно, проявляется в IE старых версий. Связано с хостингом. Увидите проблему, если попробуете открыть ссылку на картинку отдельно. Попробуйте в другом браузере.
Исчезновение прерывистых линий
 
Цитата
Maksim Grudtsyn написал:
Описанная проблема была исправлена в версии 7.1.0 терминала QUIK

Очень жаль, что снова и снова ценой новых глюков.
Имеем: версия 7.1.2.2.
Пользовательский индикатор, несколько линий.
Добавляем на график:



Пока всё хорошо. Редактируем какой-нибудь другой индикатор, жмем "Применить" и...



...о, что же это? Две разных линии уже "слились" в одну! Разумеется, со слетанием свойств линий и на графике.
Ошибка "Неверный код клиента" при выставлении заявок, Не проходят заявки выпадает ошибка
 
См. колонку "Код клиента" таблиц портфеля и лимитов (для фондового рынка). А вообще всё очень просто. Возможные значения представлены в списке выбора поля "Код Клиента" окна ввода заявки. Как правило, для фондового рынка это номер соглашения, для срочного - номер торгового счета.
UID - это код терминала, т.е. клиента сервера QUIK. К одним торговым счетам могут иметь доступ разные терминалы с разными кодами. И наоборот.
Вызов окна настроек при запуске индикатора
 
Цитата
Kolossi написал:
Ага, у меня как раз из-под wine (Mac)
Программа поддерживается только под Windows. В данном случае можно только попросить разобраться, может там дело в ерунде какой.

Цитата
Kolossi написал:
И что делать, есть варианты ?
В таком случае я делаю нужные мне настройки в Windows, а потом копирую готовый info.wnd.
Вызов окна настроек при запуске индикатора
 
Цитата
Kolossi написал:
отсутствует вкладка "Общие".
Имеются только вкладки "Дополнительно" и "Уровни".

Ага, есть такая проблема. В Linux из-под WINE у меня проявляется. И в 6-й версии так же.
Наверно, эта вкладка написана очень нестандартно.
Ошибка в создании транзакции, ОШИБКА 159
 
Варианты:
1. Попробуйте совсем убрать TYPE = L. Заявки лимитные по умолчанию.
2. Задать цену с 2-мя знаками вместо одного ("143.70").
2. Я ввел аналогичную заявку в карман транзакций и сохранил в файл. Вот что получилось:
Код
TRANS_ID=1;
CLASSCODE=TQBR;
ACTION=Ввод заявки;
Торговый счет=L01+00000F00;
К/П=Купля;
Тип=Лимитная;
Тип по цене=По разным ценам;
Тип по остатку=Поставить в очередь;
Тип ввода значения цены=По цене;
Назначение заявки=По умолчанию;
Тип события активации заявки=Обычная заявка;
Режим=TQBR;
Инструмент=GAZP;
Цена=143.70;
Лоты=1;
Примечание=;
Объем заявки=0.00;
Код внешнего пользователя=;
Время активации=;
Доп. инфо=;
Интересно, что такое параметр "Режим" (равен "CLASSCODE")? Может, проблема в его отсутствии?

Попробуйте сделать также и отправить транзакцию из кармана (предварительно сохранив в файл). Если уйдет нормально: в скрипте составьте точно такую же (именно в этом формате со всеми этими параметрами). Далее, исключая один параметр за другим (необязательные), можно будет понять, в каком из них проблема.
Ошибка в создании транзакции, ОШИБКА 159
 
Цитата
Владимир Киселев написал:

так заявка выставляется руками и проходит.

Приведите здесь полный лог всех параметров отправляемой транзакции (как вы привели ответ на нее). Может, ошибка кроется в совсем малом и незаметном.
Как управлять временем жизни стоп-заявки и как её снять по trans_id?, управление стоп-заявками
 
Цитата
В В написал:
["ORDER_KEY"] = что-то непонятное

Ничего тут непонятного нет. Это числовой номер заявки в торговой системе.

Цитата
В В написал:
как переделать ["ORDER_KEY"] и/или что-то ещё, чтобы работало?

Не надо ничего переделывать. Заявка снимаются по её номеру. После отправки отправки транзакции "NEW_ORDER" в случае успеха получаем:
Код
transReply=
  {
    ["status"]=3
    ["trans_id"]=<...>
    ["result_msg"]="Заявка, с биржевым номером 3188566693, успешно зарегистрирована."
    ["order_num"]=3188566693
    ......
  }

Запоминаем "order_num" и используем. И еще в любой момент можем его получить чтением таблицы заявок - getNumberOf() / getItem().
Ошибка в создании транзакции, ОШИБКА 159
 
Цитата
Владимир Киселев написал:
["COMMENT"]    = "Покупка бумаг скриптом"

У транзакций нет поля "COMMENT". Это только для импорта из .tri-файла для групповых операций. Правильно так:
Код
["CLIENT_CODE"]="130521/Покупка бумаг скриптом"
ну либо
Код
["CLIENT_CODE"]="/Покупка бумаг скриптом"
Ошибка в создании транзакции, ОШИБКА 159
 
Цитата
Владимир Киселев написал:
Не могу понять в чем ошибка

Странно: в ответе: [9456] OnTransReply-quantity 24
А в транзакции - 1.
Есть подозрение, что это ответ на другую транзакцию, которая действительно с ошибочными параметрами.
Попробуйте выводить в лог все отправляемые транзакции с их фактическими параметрами, а то по коду это сложно понять.
И потом спаривать их по trans_id и уже сравнивать.
getBuySellInfoEx
 
Цитата
SDL написал:
я задал вопрос брокеру

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

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

Если 202 - это входящий остаток на начало сессии, то для расчета его обеспечения всегда используется цена последнего клиринга, а значит, значение базового ГО. Если вам принудительно не закрывают позиции, это просто означает, что обеспечение достаточное.
Для вычисления макс. количества в текущей сессии, как мы уже хорошо знаем, нужно задать цену заявки. Поэтому с учетом свободного лимита, надбавок/скидок по ГО количество в определенных рамках может получиться любым. Повторю, для подробного анализа нужно знать всю совокупность исходных данных.
getBuySellInfoEx
 
Цитата
Роман написал:
Данные раз в секунду обновляются
Цитата
Роман написал:
SDL, я так не пойму, у вас скрипт те же данные выдаёт, что и мой?

Сложно догадаться, как вы представляете себе процесс разработки и тестирования программного обеспечения. Наши программы могут быть устроены и работать по совершенно разным принципам, и следовательно, не будут совместимыми по порядку их работы. Где там чего раз в секунду обновляется? Общепризнано, что единственный значимый результат - чистая прибыль по итогам года.
Вы предложили вариант кода для расчета ГО. Он вполне хороший и годный. Я вам дал набор тестовых данных в виде таблички, которые по моему мнению являются правильными, для его проверки. Рассчитайте по ним ГО с помощью своего кода и сравните! Если совпадают, где проблема?
getBuySellInfoEx
 
Цитата
Роман написал:
на счете 202 , маржа с планом в плюсе, о он выводит 198
|-------------------------------------|
|____________________| = 202

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

Слева от знаков равенства клеточки, которые надо заполнить формулами и числами так, чтобы справа получились указанные значения.
Тогда мы сможем продвинуться в решении. Если так будет понятнее.
getBuySellInfoEx
 
Цитата
Роман написал:
просто опять вопрос стоит - как проверить рабочая формула или опять теоретическая
Цитата
SDL написал:
после начала расчета (корректного!) ГО по биржевой методике у меня еще ни одну заявку не отвергли по лимитам

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

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

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

Всё сказанное выше в полной мере относится и к этому вопросу.
getBuySellInfoEx
 
Цитата
Роман написал:
на счете 202 , маржа с планом в плюсе, о он выводит 198.

Можно подробнее, откуда эти числа?
getBuySellInfoEx
 
... Ну и еще оптимизация этого кода:

Код
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
getBuySellInfoEx
 
Цитата
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
getBuySellInfoEx
 
Цитата
Роман написал:
проверьте пожалуйста со своим исходными данными

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

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

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

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

По-прежнему готов обсуждать примеры и расчеты по стандартной биржевой методике.
getBuySellInfoEx
 
Цитата
Роман написал:
Другой вариант:  http://forum.moex.com/viewtopic.asp?t=30919

Правильный расчет, строго по этой методике. В чем он другой, я не могу понять? Можно конкретно сравнить и показать?
getBuySellInfoEx
 
Цитата
Роман написал:
на бирже вообще другое объяснение:  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
getBuySellInfoEx
 
Цитата
Роман написал:
формула с радиусом верна?

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

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

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

ГО - обеспечение 1 контракта.
Если ГО увеличивается, то количество - ... что?
getBuySellInfoEx
 
Цитата
Роман написал:
в параметрах инструмента это указывать
Если нужно не просто знать, а автоматизировать... Нет, параметра такого не могу назвать.
А зачем? См. выше мой способ расчета корректного ГО. Может подойдет?
getBuySellInfoEx
 
Цитата
Роман написал:
с радиусом ещё и проблема в том, что в свойствах инструментов нет указаний, нужно ли его применить к данному инструменту или нет

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

В этом документе есть их перечень ("Контракты, предусматривающие данный алгоритм расчёта вариационной маржи").
И, конечно, в спецификации инструментов. Например, по RIxx: "Стоимость минимального шага цены Контракта соответствует 20 % от курса  доллара США по отношению к российскому рублю, установленному в  соответствии с Методикой ..."
getBuySellInfoEx
 
Цитата
Sergey Gorokhov написал:
К сожалению ответ сотрудника неверный
Отсутствие учета  радиуса курса валют относится конечно же к срочному рынку.

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

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

Например, у нас покупка по цене ниже лимита. Берем ГО в рублях, делим на 2L и умножаем на 2L – (РЦ – Ц), формула из методики.
Получаем правильное ГО.
getBuySellInfoEx
 
Цитата
Stanislav Tvorogov написал:

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

Честно говоря, больше не хочется ходить по кругу.
getBuySellInfoEx
 
Ни разу не сложно привести расчет для второго примера.
Покупка по 70000, ниже расчетной цены (71550).
Имеем:

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

... что без проблем соответствует значению ГО в примере (для 1000 контрактов). И конечно, снова без учета радиуса валютного курса.
getBuySellInfoEx
 
Цитата
Sergey Gorokhov написал:
Нет не подтверждаю.
Не воспроизводится.
Потрясающе. Теперь вы против своих собственных скринов окна заявки не будете возражать? Надеюсь, вы используете актуальную версию терминала.
getBuySellInfoEx
 
Цитата
Роман написал:
так вопрос то не в том, что она меняется, а в том что не правильно меняется именно в цифрах!

Это потому, что нас слушают, но не слышат.
Пример на демо-системе, ок, там то же самое.
Возьмем первый скрин. Цена 75130, по верхнему лимиту. Введено 1000 контрактов, давайте для простоты и наглядности брать 1 контракт, ГО тогда будет 16588.68

А теперь следите за руками:
3L / MinStep * MinStepPrice = 3 * (Pmax - РЦ) / MinStep * MinStepPrice = 3 * (75130 - 71550) / 10 * 15.44570 = 16588.6818

Где учет радиуса курса USD?!
Изучаем Qlua., "hello world"
 
Цитата
Sergey Gorokhov написал:
Цитата
Валентин   написал:
if cc.bit.band(flags,0)>0 then
Это некорректное использование.
Вот так надо
if bit.band(cc.flags,0)>0 then

Приведенное условие есть тождественная ложь. Будьте внимательны.
Как зделать переворот пози?
 
Цитата
Андрей Мурга написал:
тоесть банальний реверс просто увиличить контракт не поможет робот потом запутается

Трудности аффтара теперь понятны.
Допустим, была длинная позиция +10, нужна короткая -10. Делаем:
Код
if aaa<bbb then
  sell 10 -- здесь позиция стала 0 (это и есть "закрить бай")
  sell 10 -- здесь позиция стала -10 (это и есть "открить селл")
end
getBuySellInfoEx
 
Цитата
Роман написал:
Я бы на самом деле ещё протестировал саму формулу
Именно её (их) тестированием я и занимаюсь:
Гарантийная система рынка фьючерсов и опционов
Изменения с 7 сентября 2015 года в системе расчета гарантийного обеспечения
Принципы расчета вариационной маржи и гарантийного обеспечения с использованием текущих курсов валют

Цитата
Роман написал:
иногда МАКСИМУМ, не совсем МАКСИМУМ и есть возможность докупить несколько контрактов
Не понял этого. Если на клетке со слоном написано "буйвол", не верь глазам своим? (с)

Цитата
Роман написал:
И с большими лотами.
Вовсе не исключаю каких-либо ещё проблем с расчетом ГО при определенных условиях. Однако. Приведенные примеры демонстрируют наличие проблем именно при указанных условиях. И неплохо бы изжить для начала их.
getBuySellInfoEx
 
Цитата
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

Терминал 7.0.4.10, боевые торги. Вводим лимитную заявку:
RIH6, покупка, цена=68180 (=расчетной), кол-во=1.

Видим в поле объем ГО=11 790,99.
Неправильно! При цене заявки равной расчетной должны увидеть величину базового ГО (13 913,53).
Страницы: Пред. 1 2 3 След.
Наверх