Здравствуйте, перестало работать снятие активной заявки. раньше работало Проблема в
Код
["ORDER_KEY"]=order.ordernum
SendTransaction возвращает
Код
Неправильно указан номер заявки: "1892945602368303900.000000"
Если посмотреть на скриншот
При конкатенации со строкой и выводе в окно системных сообщения получаем 1.8929456023683e+018
1892945602368303900 не совпадает с номером заявки на скриншоте 1892 945 602 368 303 872
В какую сторону копать, quik 7.6.1.1
Пользователь
Сообщений: Регистрация: 23.01.2020
13.10.2020 16:18:51
Если писать tostring в order.ordernum
Код
["ORDER_KEY"]=tostring(order.ordernum)
Код
Неправильно указан номер заявки: "1.8929456023683e+018 "
Т.е. поломалось что-то в order.ordernum при получении из getOrders(seccode)
Пользователь
Сообщений: Регистрация: 01.07.2020
13.10.2020 16:27:23
Цитата
Aleksandr написал: В какую сторону копать, quik 7.6.1.1
Пользователь
Сообщений: Регистрация: 25.09.2020
13.10.2020 16:33:08
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
Пользователь
Сообщений: Регистрация: 23.01.2020
13.10.2020 16:50:51
дайте пожалуйста ссылку на код функции d0
Пользователь
Сообщений: Регистрация: 25.09.2020
13.10.2020 16:54:04
Aleksandr, Да её, по-моему, как раз отметившийся тут Игорь, и придумал. А я украл и переделал в функцию. Вот она:
Код
function d0(s) -- обрезка концевых нулей после запятой
s=tonumber(s); -- для числовых переменных
if s==math.floor(s) then s=math.floor(s) end
return s; -- возвращаем огрызок
end; -- конец функции d0()
Пользователь
Сообщений: Регистрация: 23.01.2020
13.10.2020 17:15:27
Владимир, спасибо, но проблему решить это не помогло. Проблема в том что
в таблице заявок 1892 945 602 368 303 872 при получении из
Код
order=getItem("orders",i)
превращается в 1892945602368303900.000000 т.е. немного округляется
Пользователь
Сообщений: Регистрация: 25.09.2020
13.10.2020 17:31:01
Хм... GetCell возвращает таблицу, у которой есть как image (строковое представление значения в ячейке), так и value (числовое значение). Может, и в getItem что-то подобное есть - она ведь тоже "возвращает таблицу Lua"... А вообще я уже не раз матерился на "динамический тип данных". Руки бы пообрывал изобретателям"!
Пользователь
Сообщений: Регистрация: 25.09.2020
13.10.2020 17:55:23
Aleksandr, Кстати, а Вы не пробовали ["ORDER_KEY"]=tostring(d0(order.ordernum)); Может, НА ТОЙ СТОРОНЕ воспримут значение как целое?
Пользователь
Сообщений: Регистрация: 21.02.2015
13.10.2020 18:09:24
Что с вами не так? Игорь вас же уже направил на правильный путь. В луа 5.1 по-умолчанию Double - не влезают 19-ти значные заявки в Double физически.
Пользователь
Сообщений: Регистрация: 21.02.2015
13.10.2020 18:14:34
Aleksandr,можно получать OnTransReply и в result_msg вытащить номер заявки. Больше ни как не получится.
Пользователь
Сообщений: Регистрация: 25.09.2020
13.10.2020 18:25:23
Александр, А зачем там вообще double? Код заявки - ЦЕЛОЕ число! Эксперимент показал, что его разрядности достаточно. Какому дебилу понадобилось объединить int и float в идиотский number, да ещё и на уровне исполнения использовать именно float? Мало других способов поймать приключения на свою задницу?
Пользователь
Сообщений: Регистрация: 23.01.2015
13.10.2020 18:40:10
Цитата
Владимир написал: , А зачем там вообще double? Код заявки - ЦЕЛОЕ число! Эксперимент показал, что его разрядности достаточно. Какому дебилу понадобилось объединить int и float в идиотский number, да ещё и на уровне исполнения использовать именно float? Мало других способов поймать приключения на свою задницу?
Просьба сдерживаться в выражениях иначе придется принять меры.
The type number uses two internal representations, or two subtypes, one called integer and the other called float.
Пользователь
Сообщений: Регистрация: 25.09.2020
13.10.2020 18:51:52
Sergey Gorokhov,Да я всегда спокоен - это просто стиль такой.
В 64-разрядный integer спокойно влезают даже 20-значные числа - более 18 квинтиллионов!
Пользователь
Сообщений: Регистрация: 21.02.2015
13.10.2020 21:53:49
Цитата
Владимир написал: , А зачем там вообще double? Код заявки - ЦЕЛОЕ число! Эксперимент показал, что его разрядности достаточно. Какому дебилу понадобилось объединить int и float в идиотский number, да ещё и на уровне исполнения использовать именно float? Мало других способов поймать приключения на свою задницу?
Как бы по мягче сказать, что вы не разбираетесь в теме. Повторю в квике 7, lua 5.1 - в нем не числа хранятся типом double, соотвественно нельзя хранить int64. В квике начиная с 8.4 lua 5.3 - числа хранятся в int64 - все работает.
Цитата
В какую сторону копать, quik 7.6.1.1
Поняли? Я уже сомневаюсь в ваших способностях в чем-то разбираться.
Пользователь
Сообщений: Регистрация: 25.09.2020
13.10.2020 22:02:09
Александр, Да я и не собираюсь разбираться в такой теме! Если вместо нормального инта используется float, значит, у разработчиков вместо головы задница. Тем более, что Сергей сказал, что "type number uses two internal representations, or two subtypes".
Для справки: ВЕЗДЕ, где хранятся данные типа double, МОЖНО хранить и int64 (int32, Int 16, int8 и прочее - это просто кусок памяти! И в этой "теме" я разобрался лет эдак 40 назад..
Пользователь
Сообщений: Регистрация: 21.08.2015
13.10.2020 23:00:53
Цитата
Владимир написал: ВЕЗДЕ, где хранятся данные типа double, МОЖНО хранить и int64 (int32, Int 16, int8 и прочее - это просто кусок памяти!
К сожалению нет уже. Сейчас это не обязательно восемь байт в памяти, это может быть регистр, причем для интов это будет целый регистр, а для флотов уже даже не fpu, а xmm. А эти последние хотят еще и выравнивания на 16 байт. То есть даже на асме попытаться безбашенно воткнуть в xmm произвольные восемь байт может закончиться крэшем. Да и в старые добрые времена x87 операция fld qword ptr могла выкинуть исключение, если там вдруг окажется денормализованное число. А тут вообще сишный компилятор, он имеет свое мнение, где что ожидать, попросить его по дружбе загрузить флот в rax не получится.
Пользователь
Сообщений: Регистрация: 25.09.2020
13.10.2020 23:09:44
Anton, Какая разница? Насколько я помню, копирование СТРОК наиболее быстро производится через регистры сопроцессора (fld-fstp). Тип int тоже, по большому счёту, разновидность типа var - я всегда пользуюсь i16 или i32. Вот со стеком хуже: запихиваешь туда байт, а он, паскуда, пихает, что ему в голову взбредёт. И выравнивание структур, как компилятору в головожопу вдарит... странно, что вся эта софтина до сих пор хоть как-то работает! В любом случае, тип int отличается от типа float только разной интерпретацией входящих туда битов.
обновился до 8.5.2.11, проблема ушла, всем спасибо!
Пользователь
Сообщений: Регистрация: 30.01.2015
16.10.2020 08:28:18
Цитата
Владимир написал: ,Да я всегда спокоен - это просто стиль такой. ::
В 64-разрядный integer спокойно влезают даже 20-значные числа - более 18 квинтиллионов!
Для справки : Разрядность мантиссы в 64 битном вещественном числе составляет 52 бита, что позволяет точно отобразить лишь 16 разрядное десятичное целое число . а не 18 квинтиллионов, как наивно полагает Владимир.
Пользователь
Сообщений: Регистрация: 25.09.2020
16.10.2020 08:43:39
nikolz,При чём тут "мантисса", милок? Да будет Вам известно, что в целочисленных типах НЕТ Никакой "мантиссы"! Там работают ВСЕ 64 разряда до единого, и результат не округляется НИКОГДА! А теперь берём калькулятор в левую руку:
0xFFFFFFFFFFFFFFFF в десятичной системе счисления составит 18 446 744 073 709 515 615