Доброго времени суток. В Lua, я совсем новенький, так что просьба не ругаться за банальные вопросы. Я собираюсь записывать историю историю изменения отрытого интереса в бинарный файл, для дальнейшего анализа в другой программе. В формате: Дата Время Цена Last Значение интереса 12.02.2024 16.42.01.074:074244 12.298 20000 Время тика хочу записывать в posix формате(unix время, long 64 бита), но обнаружил что в Lua это время с точностью до секунд, и не микросекунд. Поиск решения внятного ответа не дал, видел что на форуме поднимался этот вопрос, но так ни к чему вроде как и не пришли. Можно ли только средствами языка Lua решить этот вопрос, или надо писать костыли?
Для цены хотел использовать double(64 бита), а для открытого интереса integer(32 бита). И вроде как в Lua 5.3 появился целочисленный тип, но я так понял Lua c динамической типизацией, сам присваивает как ему кажется правильней тип, и напрямую это ему не указать. Но в других источниках я читал, что number всегда занимает место 64 бита в формате double, даже если записано целочисленное значение. Так как все-таки Lua записывает числа?
И если все-таки размер number меняется, то может ли userdata послужить решением в этом вопросе? Возможно если сам не разберусь, отдам задачу более квалифицированному человеку, но хотелось бы все равно понять, как будет действовать Lua в квике, при записи бинарного файла. Знаю что можно просто все писать в csv, но не хочу тратить время на преобразование строк в числа, хоть и не претендую на HFT, но хотелось бы меньше лишних движений.
snurhel, Это называется "искать на свою задницу приключений". Записывайте в текстовом формате и забудьте про все эти "проблемы". А в "другой программе" читайте это и заполняйте те структуры, которые Вам угодно - double, integer - INT64, INT32, INT16, INT8, UNSIGNED или ещё что. Ах, так Вы и сами знаете про csv. ЗАБУДЬТЕ! Время на преобразование строк в числа ничтожно по сравнению с файловыми операциями. Не говоря уже о том, что время чтения исходных данных ничтожно по сравнению с временем их обработки.
snurhel написал: Но в других источниках я читал, что number всегда занимает место 64 бита в формате double, даже если записано целочисленное значение. Так как все-таки Lua записывает числа?
Lua под х64 записывает числа в форматах int64 (только со знаком), и double (тоже 64). У них там в доке сказано, что тип integer это подтип типа number.
Если заглянуть в потроха Lua, то можно усечь, что в байтике, в котором хранится тип переменной number, для integer установлен дополнительный битик. Из-за того, что раньше (говорят, до вер. 5.3) в Lua не было целочисленного типа, теперь в выдаче скриптов приходится видеть дробные значения в полях qty (quantity, количество акций): напр., 12345.0. А при вызовах функций qlua, говорят, этот нолик с точкой надо убирать, напр., через math.floor(order.qty).
snurhel написал: Доброго времени суток. В Lua, я совсем новенький, так что просьба не ругаться за банальные вопросы. Я собираюсь записывать историю историю изменения отрытого интереса в бинарный файл, для дальнейшего анализа в другой программе. В формате: Дата Время Цена Last Значение интереса 12.02.2024 16.42.01.074:074244 12.298 20000 Время тика хочу записывать в posix формате(unix время, long 64 бита), но обнаружил что в Lua это время с точностью до секунд, и не микросекунд. Поиск решения внятного ответа не дал, видел что на форуме поднимался этот вопрос, но так ни к чему вроде как и не пришли. Можно ли только средствами языка Lua решить этот вопрос, или надо писать костыли?
Для цены хотел использовать double(64 бита), а для открытого интереса integer(32 бита). И вроде как в Lua 5.3 появился целочисленный тип, но я так понял Lua c динамической типизацией, сам присваивает как ему кажется правильней тип, и напрямую это ему не указать. Но в других источниках я читал, что number всегда занимает место 64 бита в формате double, даже если записано целочисленное значение. Так как все-таки Lua записывает числа?
И если все-таки размер number меняется, то может ли userdata послужить решением в этом вопросе? Возможно если сам не разберусь, отдам задачу более квалифицированному человеку, но хотелось бы все равно понять, как будет действовать Lua в квике, при записи бинарного файла. Знаю что можно просто все писать в csv, но не хочу тратить время на преобразование строк в числа, хоть и не претендую на HFT, но хотелось бы меньше лишних движений.
У Вас много вопросов и не понятно, на какой отвечать, но попробую. ---------------------- Луа хранит числа в двух форматах double(8 байт ) и long (4 байта) ------------------------ Хранятся эти числа в структуре . В этой же структуре хранятся и указатели. ------------------------ Поэтому размер не зависит от типа данных. ------------------------- Писать бинарный файл можно как запись строк. Луа пишет в файл все байты вне зависимости от значения байта . ----------------------- Время с дискретом 0.1 мкс можно получить используя API C for lua. Т е написав или взяв в интернете функцию высокоточного чтения времени. ================ Но я бы рекомендовал Вам сначала разобраться с реальными задержками данных поступающими в терминал и скоростью реакции вашей программы на их изменение. Потом решать, какие точности измерений Вам необходимы.
nikolz написал: Луа хранит числа в двух форматах double(8 байт ) и long (4 байта)
Насколько я понимаю, у Луа, скомпилированного под 32-разрядную Виндовс, будут форматы float и long (по 4 байта), а если Луа скомпилирован под 64-разрядную Виндовс, то числовые форматы будут только double и int64 (по 8 байтов).
nikolz написал: Луа хранит числа в двух форматах double(8 байт ) и long (4 байта)
Насколько я понимаю, у Луа, скомпилированного под 32-разрядную Виндовс, будут форматы float и long (по 4 байта), а если Луа скомпилирован под 64-разрядную Виндовс, то числовые форматы будут только double и int64 (по 8 байтов).
уже нет квиков под 32 разрядную версию, так как для хранения номеров сделок надо 64 бита.
nikolz написал: Луа хранит числа в двух форматах double(8 байт ) и long (4 байта)
Насколько я понимаю, у Луа, скомпилированного под 32-разрядную Виндовс, будут форматы float и long (по 4 байта), а если Луа скомпилирован под 64-разрядную Виндовс, то числовые форматы будут только double и int64 (по 8 байтов).
не возражаю , так как в луа это одна и та же структура.
а для 64-разрядных целых чисел определены специальные новые типы данных.
--------------------------------
Linux: размер long становится 64-разрядным, в то время как размер int остается 32-разрядным в 64-разрядных версиях Linux.
=========================== Распространенные проблемы с 64-разрядной миграцией Visual C ++
При использовании компилятора Microsoft C ++ (MSVC) для создания приложений для запуска в 64-разрядной операционной системе Windows вам следует знать о следующих проблемах:
int и a long являются 32-разрядными значениями в 64-разрядных операционных системах Windows.
Для программ, которые вы планируете компилировать для 64-разрядных платформ, следует соблюдать осторожность и не назначать указатели на 32-разрядные переменные.
Указатели являются 64-разрядными на 64-разрядных платформах, и вы усечете значение указателя, если присвоите его 32-разрядной переменной.
size_t, time_t и ptrdiff_t являются 64-разрядными значениями в 64-разрядных операционных системах Windows.
time_t это 32-разрядное значение в 32-разрядных операционных системах Windows в Visual Studio 2005 и более ранних версиях. time_t теперь по умолчанию это 64-разрядное целое число.
Вы должны знать, где ваш код принимает int значение и обрабатывает его как size_t или time_t значение. Возможно, что число может вырасти до 32-разрядного числа, и данные будут усечены при их передаче обратно в int хранилище.
Модификатор %x (шестнадцатеричный int формат) printf не будет работать должным образом в 64-разрядной операционной системе Windows. Он будет работать только с первыми 32 битами передаваемого ему значения.
Используйте %I32x для отображения 32-разрядного интегрального типа в шестнадцатеричном формате.
Используйте %I64x для отображения 64-разрядного интегрального типа в шестнадцатеричном формате.
%p (шестнадцатеричный формат указателя) будет работать должным образом в 64-разрядной операционной системе Windows.
В QUIK в Lua инты 64 бита. Данные по тикам в документации к CreateDataSource:
Цитата
Время свечи возвращается с точностью до миллисекунд в виде таблицы с полями: {year, month, day, week_day, hour, min, sec, ms, count} Где: • count – количество тиковых интервалов в секунду. Может принимать значения от «1» до «10000» включительно.
Используя Lua функцию os.time из таблицы, полученной от T(номер свечи), можно получить секунды от эпохи (какой именно - поставьте эксперимент и напишите результат). А из полей ms и count - количество миллисекунд и десятых миллисекунд. Для перевода из виндовой эпохи в никсовую гуглите "SECS_BETWEEN_1601_AND_1970_EPOCHS"
Пишите текстовый файл и не парьте себе мозги. Текстовый файл проще отлаживать (можно глазами посмотреть), проще поддерживать. На скорость в общей инфраструктуре работы терминала это не повлияет совершенно.