перестало работать снятие активной заявки

Страницы: 1
RSS
перестало работать снятие активной заявки
 
Здравствуйте,
перестало работать снятие активной заявки. раньше работало
Проблема в

Код
["ORDER_KEY"]=order.ordernum
SendTransaction возвращает

Код
Неправильно указан номер заявки: "1892945602368303900.000000"


Если посмотреть на скриншот https://prnt.sc/uygi03

При конкатенации со строкой и выводе в окно системных сообщения получаем 1.8929456023683e+018

1892945602368303900 не совпадает с номером заявки на скриншоте 1892 945 602 368 303 872

В какую сторону копать, quik 7.6.1.1
 
Если писать tostring в order.ordernum
Код
["ORDER_KEY"]=tostring(order.ordernum)
Код
 Неправильно указан номер заявки: "1.8929456023683e+018 "
Т.е. поломалось что-то в order.ordernum при получении из getOrders(seccode)
 
Цитата
Aleksandr написал:
В какую сторону копать, quik 7.6.1.1
https://forum.quik.ru/forum1/topic5117/
 
Aleksandr, Ошибка, очевидно, в формате представления данных с плавающей точкой. Чуть-чуть поигрался - получилось так:
Код:
i=1892945602368303872;
j=1892945602368303872.0000;
s=tostring(i);
message(s.."\n"..i.."\n"..j);
Результат:
1892945602368303872
1892945602368303872
1.8929456023683e+18

Как ни странно, помогла недавно разбиравшаяся тут d0, обрезающая концевые нули:
Код:
i=1892945602368303872;
j=1892945602368303872.0000;
j=d0(j);
s=tostring(i);
message(s.."\n"..i.."\n"..j);
Результат:
1892945602368303872
1892945602368303872
1892945602368303872
 
дайте пожалуйста ссылку на код функции d0
 
Aleksandr, Да её, по-моему, как раз отметившийся тут Игорь, и придумал.  :smile: А я украл и переделал в функцию. Вот она:
Код
function d0(s)         -- обрезка концевых нулей после запятой
 s=tonumber(s);         -- для числовых переменных
 if s==math.floor(s) then s=math.floor(s) end
 return s;         -- возвращаем огрызок
end;            -- конец функции d0()
 
Владимир, спасибо, но проблему решить это не помогло.
Проблема в том что

в таблице заявок 1892 945 602 368 303 872
при получении из  

Код
order=getItem("orders",i)
превращается в 1892945602368303900.000000
т.е. немного округляется
 
Хм... GetCell возвращает таблицу, у которой есть как image (строковое представление значения в ячейке), так и value (числовое значение). Может, и в getItem что-то подобное есть - она ведь тоже "возвращает таблицу Lua"... А вообще я уже не раз матерился на "динамический тип данных". Руки бы пообрывал изобретателям"!
 
Aleksandr, Кстати, а Вы не пробовали
["ORDER_KEY"]=tostring(d0(order.ordernum));
Может, НА ТОЙ СТОРОНЕ воспримут значение как целое?  
 
Что с вами не так? Игорь вас же уже направил на правильный путь.  В луа 5.1 по-умолчанию Double - не влезают 19-ти значные заявки в Double физически.  :shock:  
 
Aleksandr,можно получать OnTransReply и в result_msg вытащить номер заявки. Больше ни как не получится.
 
Александр, А зачем там вообще double? Код заявки - ЦЕЛОЕ число! Эксперимент показал, что его разрядности достаточно. Какому дебилу понадобилось объединить int и float в идиотский number, да ещё и на уровне исполнения использовать именно float? Мало других способов поймать приключения на свою задницу?
 
Цитата
Владимир написал:
Александр, А зачем там вообще double? Код заявки - ЦЕЛОЕ число! Эксперимент показал, что его разрядности достаточно. Какому дебилу понадобилось объединить int и float в идиотский number, да ещё и на уровне исполнения использовать именно float? Мало других способов поймать приключения на свою задницу?

Просьба сдерживаться в выражениях иначе придется принять меры.

https://www.lua.org/manual/5.3/manual.html#2
The type number uses two internal representations, or two subtypes, one called integer and the other called float.
 
Sergey Gorokhov,Да я всегда спокоен - это просто стиль такой.  :smile:

В 64-разрядный integer спокойно влезают даже 20-значные числа - более 18 квинтиллионов!
 
Цитата
Владимир написал:
Александр, А зачем там вообще double? Код заявки - ЦЕЛОЕ число! Эксперимент показал, что его разрядности достаточно. Какому дебилу понадобилось объединить int и float в идиотский number, да ещё и на уровне исполнения использовать именно float? Мало других способов поймать приключения на свою задницу?
Как бы по мягче сказать, что вы не разбираетесь в теме.
Повторю в квике 7, lua 5.1 - в нем не числа хранятся типом double, соотвественно нельзя хранить int64.
В квике начиная с 8.4 lua 5.3 - числа хранятся в int64 - все работает.
Цитата
В какую сторону копать, quik 7.6.1.1
Поняли? Я уже сомневаюсь в ваших способностях в чем-то разбираться.
 
Александр, Да я и не собираюсь разбираться в такой теме! Если вместо нормального инта используется float, значит, у разработчиков вместо головы задница. Тем более, что Сергей сказал, что "type number uses two internal representations, or two subtypes".

Для справки: ВЕЗДЕ, где хранятся данные типа double, МОЖНО хранить и int64 (int32, Int 16, int8 и прочее - это просто кусок памяти! И в этой "теме" я разобрался лет эдак 40 назад.. :wink:  
 
Цитата
Владимир написал:
ВЕЗДЕ, где хранятся данные типа double, МОЖНО хранить и int64 (int32, Int 16, int8 и прочее - это просто кусок памяти!
К сожалению нет уже. Сейчас это не обязательно восемь байт в памяти, это может быть регистр, причем для интов это будет целый регистр, а для флотов уже даже не fpu, а xmm. А эти последние хотят еще и выравнивания на 16 байт. То есть даже на асме попытаться безбашенно воткнуть в xmm произвольные восемь байт может закончиться крэшем. Да и в старые добрые времена x87 операция fld qword ptr могла выкинуть исключение, если там вдруг окажется денормализованное число. А тут вообще сишный компилятор, он имеет свое мнение, где что ожидать, попросить его по дружбе загрузить флот в rax не получится.
 
Anton, Какая разница? Насколько я помню, копирование СТРОК наиболее быстро производится через регистры сопроцессора (fld-fstp). Тип int тоже, по большому счёту, разновидность типа var - я всегда пользуюсь i16 или i32. Вот со стеком хуже: запихиваешь туда байт, а он, паскуда, пихает, что ему в голову взбредёт. И выравнивание структур, как компилятору в головожопу вдарит... странно, что вся эта софтина до сих пор хоть как-то работает! В любом случае, тип int отличается от типа float только разной интерпретацией входящих туда битов.
 
Цитата
Игорь написал:
Цитата
Aleksandr написал:
В какую сторону копать, quik 7.6.1.1
 https://forum.quik.ru/forum1/topic5117/
обновился до 8.5.2.11, проблема ушла, всем спасибо!
 
Цитата
Владимир написал:
Sergey Gorokhov,Да я всегда спокоен - это просто стиль такой.  ::

В 64-разрядный integer спокойно влезают даже 20-значные числа - более 18 квинтиллионов!
Для справки  :
Разрядность мантиссы в 64 битном вещественном числе составляет 52 бита,
что  позволяет точно отобразить лишь 16 разрядное десятичное целое число .
а не  18 квинтиллионов, как наивно полагает Владимир.
 
nikolz,При чём тут "мантисса", милок? Да будет Вам известно, что в целочисленных типах НЕТ Никакой "мантиссы"! Там работают ВСЕ 64 разряда до единого, и результат не округляется НИКОГДА! А теперь берём калькулятор в левую руку:

0xFFFFFFFFFFFFFFFF в десятичной системе счисления составит 18 446 744 073 709 515 615

Учите матчасть!  :wink:  
Страницы: 1
Читают тему (гостей: 2)
Наверх