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
Aleksandr, Да её, по-моему, как раз отметившийся тут Игорь, и придумал. А я украл и переделал в функцию. Вот она:
Код
function d0(s) -- обрезка концевых нулей после запятой
s=tonumber(s); -- для числовых переменных
if s==math.floor(s) then s=math.floor(s) end
return s; -- возвращаем огрызок
end; -- конец функции d0()
Хм... GetCell возвращает таблицу, у которой есть как image (строковое представление значения в ячейке), так и value (числовое значение). Может, и в getItem что-то подобное есть - она ведь тоже "возвращает таблицу Lua"... А вообще я уже не раз матерился на "динамический тип данных". Руки бы пообрывал изобретателям"!
Александр, А зачем там вообще double? Код заявки - ЦЕЛОЕ число! Эксперимент показал, что его разрядности достаточно. Какому дебилу понадобилось объединить int и float в идиотский number, да ещё и на уровне исполнения использовать именно float? Мало других способов поймать приключения на свою задницу?
Владимир написал: Александр, А зачем там вообще double? Код заявки - ЦЕЛОЕ число! Эксперимент показал, что его разрядности достаточно. Какому дебилу понадобилось объединить int и float в идиотский number, да ещё и на уровне исполнения использовать именно float? Мало других способов поймать приключения на свою задницу?
Просьба сдерживаться в выражениях иначе придется принять меры.
Владимир написал: Александр, А зачем там вообще 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 назад..
Владимир написал: ВЕЗДЕ, где хранятся данные типа double, МОЖНО хранить и int64 (int32, Int 16, int8 и прочее - это просто кусок памяти!
К сожалению нет уже. Сейчас это не обязательно восемь байт в памяти, это может быть регистр, причем для интов это будет целый регистр, а для флотов уже даже не fpu, а xmm. А эти последние хотят еще и выравнивания на 16 байт. То есть даже на асме попытаться безбашенно воткнуть в xmm произвольные восемь байт может закончиться крэшем. Да и в старые добрые времена x87 операция fld qword ptr могла выкинуть исключение, если там вдруг окажется денормализованное число. А тут вообще сишный компилятор, он имеет свое мнение, где что ожидать, попросить его по дружбе загрузить флот в rax не получится.
Anton, Какая разница? Насколько я помню, копирование СТРОК наиболее быстро производится через регистры сопроцессора (fld-fstp). Тип int тоже, по большому счёту, разновидность типа var - я всегда пользуюсь i16 или i32. Вот со стеком хуже: запихиваешь туда байт, а он, паскуда, пихает, что ему в голову взбредёт. И выравнивание структур, как компилятору в головожопу вдарит... странно, что вся эта софтина до сих пор хоть как-то работает! В любом случае, тип int отличается от типа float только разной интерпретацией входящих туда битов.
В 64-разрядный integer спокойно влезают даже 20-значные числа - более 18 квинтиллионов!
Для справки : Разрядность мантиссы в 64 битном вещественном числе составляет 52 бита, что позволяет точно отобразить лишь 16 разрядное десятичное целое число . а не 18 квинтиллионов, как наивно полагает Владимир.
nikolz,При чём тут "мантисса", милок? Да будет Вам известно, что в целочисленных типах НЕТ Никакой "мантиссы"! Там работают ВСЕ 64 разряда до единого, и результат не округляется НИКОГДА! А теперь берём калькулятор в левую руку:
0xFFFFFFFFFFFFFFFF в десятичной системе счисления составит 18 446 744 073 709 515 615