19-значные номера заявок и сделок на MOEX

Страницы: 1 2 След.
RSS
19-значные номера заявок и сделок на MOEX
 
Добрый день, разработчики терминала!

Прочитал уведомление "Уведомление в связи с обновлением торговой системы срочного рынка Московской биржи (Spectra 6.3)", где говорится о 19-значных номерах заявок и сделок.

Там было написано так: Внимание! Это крайне важно!

В связи с этим вопросы:

1) Если внутри QLua для номеров заявок и сделок используются переменные числового типа, то появятся ли отрицательные значения в этих переменных?

2) Если появятся, то будет ли корректно работать постановка/снятие заявок через sendTransaction?

Просьба добавить любые другие подробности касательно того, с какими проблемами могут столкнуться роботописатели?
 
Нашёл тут на форуме комментарий Михаила Булычёва:
Цитата
Добрый день.
В Lua все числа хранятся как double, соответственно целые числа до 2^53 хранятся без потери точности.

2^53 = 9 007 199 254 740 992‬.

Тут 16 знаков. Получается, что не влезают новые 19-значные номера в Lua 5.1.

Как быть?
 
Здравствуйте,
Версия с поддержкой 19ти номеров еще не вышла и об этом явно сказано в уведомлении.
 
С этим не поспоришь. Только лучше бы знать, к чему нам готовиться. Время то уже тикает, до 16 декабря не так уж много времени осталось. Хотя бы спецификации уже есть? Номера будут строками приходить, раз они в Lua NUMBER не укладываются? Или будет обновление Lua до 5.3, где есть поддержка long на 64-бита?
 
Цитата
_sk_ написал:
С этим не поспоришь. Только лучше бы знать, к чему нам готовиться. Время то уже тикает, до 16 декабря не так уж много времени осталось. Хотя бы спецификации уже есть? Номера будут строками приходить, раз они в Lua NUMBER не укладываются? Или будет обновление Lua до 5.3, где есть поддержка long на 64-бита?
К сожалению мы не имеем права разглашать информацию до официального релиза.
 
Цитата
_sk_ написал:
2^53 = 9 007 199 254 740 992‬.
53 разряда, а не 2^53

Цитата
_sk_ написал:
к чему нам готовиться.
к худшему конечно, как обычно  :wink:  
 
Цитата
Sergey Gorokhov написал:
Цитата
_sk_ написал:
С этим не поспоришь. Только лучше бы знать, к чему нам готовиться. Время то уже тикает, до 16 декабря не так уж много времени осталось. Хотя бы спецификации уже есть? Номера будут строками приходить, раз они в Lua NUMBER не укладываются? Или будет обновление Lua до 5.3, где есть поддержка long на 64-бита?
К сожалению мы не имеем права разглашать информацию до официального релиза.
Осталось 14 дней, а программа еще не готова?  Ее же не только вы должны выпустить, но и брокеры распространить.

А что будет с версиями 7.ХХ?

Как будут отрабатывать все текущие функции, которые возвращают таблицу, в которой присутствует номер заявки или номер сделки?
Ждем официального ответа по этому поводу.
 
Работа с заявками и сделками - это базовые вещи, если вы начнете их менять на строку, то там вылезет у вас куча ошибок, и это точно вы не успеете за оставшиеся 14 дней, а нам придется переделывать все скрипты, которые торгуют.
 
Цитата
Александр М написал:
и это точно вы не успеете за оставшиеся 14 дней
Александр, не могли бы сформулировать для обчего развития суть претензии к АРКА вида:

вы, нехорошие люди, давно должны были понимать,  что число в 19 цифер в номерах срочно было очень надо, тк .... _вставить нужное_ ...
и ничего не было сделано  - позор!
 
Цитата
_sk_ написал:
где говорится о 19-значных номерах заявок и сделок.
Там еще о партициях говорится, вот где веселье-то ожидается. А по 19 знакам как всегда, кто не ленился писать unsigned, те отдыхают, все прочие выходят на субботник. Не говоря уже о любителях даблов повсюду. Тксть 640к хватит всем 2.0.
 
Цитата
новичок написал:
Цитата
Александр М написал:
и это точно вы не успеете за оставшиеся 14 дней
Александр, не могли бы сформулировать для обчего развития суть претензии к АРКА вида:

вы, нехорошие люди, давно должны были понимать,  что число в 19 цифер в номерах срочно было очень надо, тк .... _вставить нужное_ ...
и ничего не было сделано  - позор!
Чтобы что-то формулировать, надо получить ответ, что ДА проблема есть во всех существующих версиях, будет релиз, в котором будет сделано ....
И что будет сделано надо писать заранее, а не по факту. Если будут изменены типы полей на строку например, то это однозначно изменение в скриптах.
 
Беда откладывается до февраля 2020 года.

Цитата
... по просьбам пользователей в ближайшем релизе будет установлено  временное ограничение на максимальную длину номеров – 14 десятичных  цифр.

https://www.moex.com/n26101/?nt=107
 
Цитата
_sk_ написал:
Беда откладывается до февраля 2020 года.

Цитата
... по просьбам пользователей в ближайшем релизе будет установлено  временное ограничение на максимальную длину номеров – 14 десятичных  цифр.

https://www.moex.com/n26101/?nt=107
Спасибо за информацию, Новый Год пройдет спокойно и душевно.
 
Мне кажется, что наиболее подходящим решением для Lua будет возврат номеров заявок и сделок в виде строки. С этими номерами арифметические операции вряд ли кто-то производит. Номера используются в качестве ключей в таблицах. Если ключей много и хочется экономить память, то уже писатели скриптов могут этим заняться, разбивая длинные строки на более короткие подстроки и преобразовывая их в числа для формирования составных ключей.

Теоретически, можно как-то через userdata выкручиваться, чтобы сразу экономить память, но там ещё разбираться надо.
 
Цитата
_sk_ написал:
С этими номерами арифметические операции вряд ли кто-то производит.
еще как пользуются
Цитата
_sk_ написал:
возврат номеров заявок и сделок в виде строки
поздравляю, #ВСГ
 
Цитата
_sk_ написал:
Теоретически, можно как-то через userdata выкручиваться, чтобы сразу экономить память, но там ещё разбираться надо.
Для 64-битного квика можно пушить непосредственно номер как LUA_TLIGHTUSERDATA (по-хорошему это пойнтер, но кто мешает скастить, луа-то все равно) и навесить на это поле метаметод, возвращающий что-нибудь читаемое из луа, строку там или таблицу. Соответственно, кто не дергает номера, никакого оверхеда не имеет. Из сей же можно будет выдергивать голое 64-битное значение через rawget тоже без оверхеда. Но, увы, на 32-битном квике такой костыль не сработает.
 
Цитата
новичок написал:
Цитата
_sk_ написал:
С этими номерами арифметические операции вряд ли кто-то производит.
еще как пользуются
Цитата
_sk_ написал:
возврат номеров заявок и сделок в виде строки
поздравляю, #ВСГ
Приведите, пожалуйста, примеры того, как Вы работаете с номерами заявок и сделок, чтобы потребовались арифметические операции (+, 0, *, /) с этими номерами. Интересно.
 
Цитата
_sk_ написал:
примеры того, как Вы работаете с номерами заявок и сделок,
извините, но нет

Цитата
_sk_ написал:
чтобы потребовались арифметические операции
есть арифметика, есть и другие моменты
то, что можно озвучить: системы хранения и выборки должна быть вполне быстрой

но даже более тут главное - все эти вопросы совершенно пустые ... надуманные, тк лонг в qlua должен быть доступен и по массе других причин

очевидно пришло время апнуть луа до 5.3 и не потому, что 5.1 это мало, просто экосистема такова на текущий момент ( кстати  - так себе экосистема, imo )
 
У меня есть сравнения <> номеров сделок, заявок. Если они будут текстовые, то можно будет сравнить через "костыли", которые конечно будут работать медленнее. В сейчашнем  lua 14 Знаков "помещается", а 5.3 как ?
 
Цитата
Sergey Gorokhov написал:
Цитата
_sk_ написал:
С этим не поспоришь. Только лучше бы знать, к чему нам готовиться. Время то уже тикает, до 16 декабря не так уж много времени осталось. Хотя бы спецификации уже есть? Номера будут строками приходить, раз они в Lua NUMBER не укладываются? Или будет обновление Lua до 5.3, где есть поддержка long на 64-бита?
К сожалению мы не имеем права разглашать информацию до официального релиза.
Не имеете право разглашать, до выхода какого релиза? Квика нового или имеется ввиду обновления Spectra ?
 
Цитата
Vladimir написал:
Не имеете право разглашать, до выхода какого релиза? Квика нового или имеется ввиду обновления Spectra ?

До выхода терминала QUIK который будет приурочен к обновлению Spectra с 19ти значными номерами.
Биржа говорит что это произойдет не раньше февраля 2020 г.
 
Цитата
Sergey Gorokhov написал:
До выхода терминала QUIK который будет приурочен к обновлению Spectra с 19ти значными номерами.Биржа говорит что это произойдет не раньше февраля 2020 г.
Подскажите, изменения не скоро случатся?
На СПБ хоть и не 19ти значные номера, а 17-ти, но тоже не помещаются в number без потери точности
 
Цитата
Владимир написал:
Подскажите, изменения не скоро случатся?

В промышленной системе изменение запланировано на апрель 2020 года, см. https://www.moex.com/n26656/?nt=107
 
Цитата
Sergey Gorokhov написал:
Цитата
Владимир написал:
Подскажите, изменения не скоро случатся?

В промышленной системе изменение запланировано на апрель 2020 года, см.  https://www.moex.com/n26656/?nt=107
Это у Мосбиржи запланировано на апрель, а у вас когда запланировано? Обновление QUIK должно выйти заранее, как минимум за 2-3 недели (а лучше больше) до перехода у Мосбиржи. Еще брокеры обновить ПО должны, потом клиентам выслать.
 
Цитата
Александр М написал:
Цитата
Sergey Gorokhov написал:
 
Цитата
Владимир  написал:
Подскажите, изменения не скоро случатся?
 
В промышленной системе изменение запланировано на апрель 2020 года, см.   https://www.moex.com/n26656/?nt=107  
Это у Мосбиржи запланировано на апрель, а у вас когда запланировано? Обновление QUIK должно выйти заранее, как минимум за 2-3 недели (а лучше больше) до перехода у Мосбиржи. Еще брокеры обновить ПО должны, потом клиентам выслать.
Добрый день.

Обновления обязательно выйдут заранее, чтобы брокера успели обновить свои системы.
 
а в старых версиях квика можно будет работать с текстовыми номерами заявок?
 
Поскольку разработчики терминала имеют возможность проверить поведение терминала на тестовом полигоне МосБиржи и это не связано с релизом 8-й версии, просьба к ним дать ответ на вопросы.

В рамках QLua,  если используются 19-значные номера сделок, что терминал версии 7.xx возвращает в полях:
* trade_num таблицы, приходящей в функции обратного вызова OnTrade;
* order_num таблицы, приходящей в функции обратного вызова OnTransReply;
* order_num таблицы, приходящей в функции обратного вызова OnOrder?
Желательно с примером, какой был номер на бирже и как этот номер отображается в QLua.

Я предполагаю, что номера сделок с потерей числовой точности. Если да, то выходит, что алготрейдинг в 7-й версии терминала с использованием QLua станет невозможным на срочном рынке.
 
Цитата
_sk_ написал:
выходит, что алготрейдинг в 7-й версии терминала с использованием QLua станет невозможным на срочном рынке.

ранее мы уже говорили что в старых версиях есть проблема и она будет исправлена, но исправление точно будет не в 7х версиях.
так что да, можно говорить о том что на старых версиях корректная работа будет невозможна.
 
Цитата
Sergey Gorokhov написал:
ранее мы уже говорили что в старых версиях есть проблема и она будет исправлена, но исправление точно будет не в 7х версиях.так что да, можно говорить о том что на старых версиях корректная работа будет невозможна
но текстовый номер заявки всё равно приходит в сообщении о транзакции? Его можно будет использовать, хоть он и 19 значный?
 
Цитата
Дмитрий написал:
но текстовый номер заявки всё равно приходит в сообщении о транзакции?
Да приходит.

Цитата
Дмитрий написал:
Его можно будет использовать, хоть он и 19 значный?
да можно, при условии что нигде в коде не будет преобразования строка->число или обратно
Нам не известно какая логика у Вас в скриптах, если для Вашей логики подойдет такое решение, значит Вам повезло.
 
Цитата
Sergey Gorokhov написал:
да можно, при условии что нигде в коде не будет преобразования строка->число или обратноНам не известно какая логика у Вас в скриптах, если для Вашей логики подойдет такое решение, значит Вам повезло.
Спасибо успокоили. Нигде не преобразовывается.
А ещё подскажите по поводу второго изменения биржи о так называемом раздельном учёте заявок по коду актива. Надеюсь клиентских терминалов это не коснётся и все изменения будут на уровне сервера?
 
Цитата
Дмитрий написал:
А ещё подскажите по поводу второго изменения биржи о так называемом раздельном учёте заявок по коду актива. Надеюсь клиентских терминалов это не коснётся и все изменения будут на уровне сервера?

не коснется
 
Цитата
но текстовый номер заявки всё равно приходит в сообщении о транзакции? Его можно будет использовать, хоть он и 19 значный?

Такое есть только в OnTransReply, но нет в OnTrade, OnOrder, так что эта информация особенно не поможет, т.к. на одном OnTransReply далеко не уехать.
Цитата
что терминал версии 7.xx возвращает в полях:
* trade_num таблицы, приходящей в функции обратного вызова OnTrade;
* order_num таблицы, приходящей в функции обратного вызова OnTransReply;
* order_num таблицы, приходящей в функции обратного вызова OnOrder?
Желательно с примером, какой был номер на бирже и как этот номер отображается в QLua.

Вопрос остался без ответа. Можете привести реальный пример типа: на бирже был номер заявки 9876543210987654321, внутри QLua это будет видно как ... (и привести значение, которое в QLua получится). Тогда явно будет видно, с какими проблемами столкнёмся.
 
_sk_,

Зачем? разве одного только факта что они будут некорректные не достаточно?
Какая разница в чем именно будет заключаться некорректность, она просто будет и всё.
 
Цитата
_sk_ написал:
на бирже был номер заявки 9876543210987654321, внутри QLua это будет видно как
Уже есть конкретика, как это будет видно: https://forum.quik.ru/messages/forum10/message41712/topic5021/#message41712
 
Цитата
Зачем? разве одного только факта что они будут некорректные не достаточно?

Возможно, что по некорректным значениям из QLua можно с помощью каких-либо преобразований и внешней информации восстановить-таки корректные значения.

Если происходит потеря точности, когда последовательные номера отображаются в одинаковые числа, тогда уже всё пропало.
 
Цитата
Anton написал:
Цитата
_sk_ написал:
на бирже был номер заявки 9876543210987654321, внутри QLua это будет видно как
Уже есть конкретика, как это будет видно:  https://forum.quik.ru/messages/forum10/message41712/topic5021/#message41712
Если это действительно так, то спасибо за пример.
 
Цитата
_sk_ написал:
Такое есть только в OnTransReply, но нет в OnTrade, OnOrder, так что эта информация особенно не поможет, т.к. на одном OnTransReply далеко не уехать.
зачем вам "даблы" для номеров транзакций? эти номера не предназначены для каких либо вычислений
 
Цитата
Дмитрий написал:
зачем вам "даблы" для номеров транзакций?
Проблема не столько в числах, хотя, если скрипт подгружает длл, парсить в ней строки будет печально. Дело еще в том, что квику придется запихивать в луа номера трейдов не только ваших, но и из ТВС, а их там очень много и они не повторяются. То есть все вот эти миллионы строчек будут аллоцированы из кучи в режиме "по одной". Получим оверхед как по расходу памяти, так и по нагрузке на процессор, причем получим все, и кому эти номера нужны, и кому нет. Выше предлагал пушить номера в числовом виде как LUA_TLIGHTUSERDATA, скастив к указателю,  и добавить поле-метаметод для получения строки из этого поля на лету. Также можно заменить старые поля с номерами в таблицах метаметодами, возвращающими даблы для совместимости. В итоге: кто не берет номеров - оверхеда не имеет, кто берет из сей - оверхеда не имеет, кто берет строками - имеет только на тех номерах, которые взял. Хак не заработает на версии 7 и ниже, дык вроде их фиксить и не собираются.
 
Цитата
Anton написал:
Дело еще в том, что квику придется запихивать в луа номера трейдов не только ваших, но и из ТВС
мне не нужны номера сделок и искать их в таблице всех сделок мне точно не нужно. А с заявками всё просто
 
Цитата
Дмитрий написал:
мне не нужны номера сделок и искать их в таблице всех сделок мне точно не нужно
Оно вам не нужно, а память и процессор жрать будет как не в себя, о чем и речь. А мне, например, нужны номера сделок из ТВС, и вариант "их там не будет" меня не устраивает.
 
Цитата
Anton написал:
Оно вам не нужно, а память и процессор жрать будет как не в себя, о чем и речь.
так если не обращаться к таблице всех сделок откуда процессор то, что то я не улавливаю
 
Цитата
Дмитрий написал:
если не обращаться
Хм, ну если только квик генерирует луа-таблицы в момент обращения, тогда да, что-то такой очевидный вариант я упустил из виду. Но тогда весь оверхед мой. В общем, надо пыль с одбц сдуть на всякий случай.
 
Для арки - как бы могло выглядеть предлагаемое выше изменение в коде квика (ровно две строчки). Очевидно, этот примитив можно выкатить за пару дней, он ничего не сломает, главное не пропустить все места, где пушится номер сделки или заявки. На выходе - кому не надо, тому и не надо, две строчки без аллокаций не оверхед, кому надо - из луа поля можно копировать, сравнивать, использовать как ключ в таблицах, преобразовывать в строку (про метаметоды я погорячился, там из коробки все есть); из сей можно просто получить void * и скастить обратно в число.
Код
void call_OnAllTrade(lua_State * s, const quik_all_trades_table_entry * pentry)
{
   // пушим вызываемую функцию
   lua_getfield(s, LUA_GLOBALSINDEX, "OnAllTrade");
   // пушим таблицу для передачи в OnAllTrade
   lua_newtable(s);
   // trade_num оставляем для совместимости
   lua_pushnumber(s, static_cast<double>(pentry->trade_num));
   lua_setfield(s, -2, "trade_num");
// НАЧАЛО ИЗМЕНЕНИЙ
   // поле номера сделки, условно "raw_trade_num"
   lua_pushlightuserdata(s, reinterpret_cast<void *>(pentry->trade_num));
   lua_setfield(s, -2, "raw_trade_num");
// КОНЕЦ ИЗМЕНЕНИЙ
   // далее все как было раньше
   lua_pushnumber(s, pentry->flags);
   lua_setfield(s, -2, "flags");
   // ...
   // и делаем вызов
   lua_call(s, 1, 0);
}
 
По америке начали возвращать номер заявки в 15-ти знаках. брокер Финам
Код
a=317934958413900
message (tostring(a))

Результат "3.179349584139e+014"

В результате уже сейчас нельзя отправить транзакцию на удаление данной заявки, т.к. там поле ['ORDER_KEY'] заполняется в виде строки.

Номер заявки брался напрямую из таблицы orders, как значение поля row.order_num

{["TRANS_ID"]="1593703383",["SECCODE"]="AMD.US",["ACTION"]="KILL_ORDER",["ACCOUNT"]="MCU1100",["ORDER_KEY"]="3.179349584139e+014",["CLASSCODE"]="STOCK_USA",}

Ответ по транзакции понятен:

"Ошибка транзакции 1593703383  Неправильно указан номер заявки: "3.179349584139e+014""

Что делать разработчики? Это не апрель, это уже сейчас.
 
Цитата
Александр М написал:
По америке начали возвращать номер заявки в 15-ти знаках. брокер ФинамКодa=317934958413900
message (tostring(a))Результат "3.179349584139e+014"
Добрый день.
Попробуйте так

string.format('%0.17g', order_num)

Перед тем как задать вопрос, убедитесь, что решение Вашей задачи не описано в официальном мануале - 'Использование Lua в Рабочем месте QUIK.pdf' https://arqatech.com/upload/Public/quik_lua.zip
 
Цитата
Александр М написал:
Что делать разработчики? Это не апрель, это уже сейчас.

Конкретно с этим кейсом ничего не делают и не будут делать, и даже если захотят ничего не смогут сделать т.к. проблема НЕ в QUIK, а конкретно  в функции tostring, которая является частю самого Lua, который не является нашей разработкой.

Попробуйте использовать другую функцию
Код
a=317934958413900
message(string.format("%.f",a))
 
Цитата
Sergey Gorokhov написал:
Цитата
Александр М написал:
Что делать разработчики? Это не апрель, это уже сейчас.

Конкретно с этим кейсом ничего не делают и не будут делать, и даже если захотят ничего не смогут сделать т.к. проблема НЕ в QUIK, а конкретно  в функции tostring, которая является частю самого Lua, который не является нашей разработкой.

Попробуйте использовать другую функцию
Код
  a =  317934958413900 
 message ( string.format ( "%.f" ,a))
  
Я правильно понял ваш ответ, что после Вашего обновления и перехода на 19-ти значные номера заявок и сделок функцией tostring в рамках данных номеров пользоваться будет нельзя?
 
Цитата
Александр М написал:
Я правильно понял ваш ответ, что после Вашего обновления и перехода на 19-ти значные номера заявок и сделок функцией tostring в рамках данных номеров пользоваться будет нельзя?


никто такого не говорил, не пытайтесь читать между строк.
Пока непонятно что будет с tostring
 
Цитата
Sergey Gorokhov написал:
Цитата
Александр М написал:
Я правильно понял ваш ответ, что после Вашего обновления и перехода на 19-ти значные номера заявок и сделок функцией tostring в рамках данных номеров пользоваться будет нельзя?


никто такого не говорил, не пытайтесь читать между строк.
Пока непонятно что будет с tostring
А когда станет понятно? Остался месяц, мы со своей стороны должны подготовить скрипты к корректной работе после изменения с Вашей стороны.
Страницы: 1 2 След.
Читают тему
Наверх