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

Страницы: 1
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 как ?
Страницы: 1
Читают тему (гостей: 1)
Наверх