агрегировать значения из таблицы сделок по временному условию
Пользователь
Сообщений: Регистрация: 05.07.2019
02.03.2021 16:09:48
Коллеги, добрый день. Пытаюсь получить агрегированную сумму по long сделкам, которые были совершены после определенного времени. Информацию пытаюсь получить из таблицы trades. Никак не получается корректно выставить условие на соответствие времени сделки. Подскажите плиз в чем косяк - как правильно обратиться? В скрипте ниже пытаюсь получить агрегированное значение по long сделкам, которые прошли после 12 часов. Соответсвенно функция ничего не возвращает. Без временного условия все работает как надо. Спасибо
Код
function aggrF()
LongValue=0 -- здесь рассчитываю кумулятивное значение из столбца объем таблицы сделок
for i = 0, getNumberOf("trades") - 1 do
if bit.band(getItem("trades",i).flags,4)> 0 and getItem("trades",i).sec_code == SecCode and getItem("trades",i).datetime.hour > 12 then-- сделка на продажу по конкр. инструменту
LongValue = getItem("trades",i).value+LongValue
end
end
return LongValue
end
Пользователь
Сообщений: Регистрация: 18.12.2017
02.03.2021 18:52:57
Чуть подкорректировал (после 12 часов это ">="):
Код
local SecCode = "RIH1"
function aggrF(direction)
local value=0 -- здесь рассчитываю кумулятивное значение из столбца объем таблицы сделок
for i = 0, getNumberOf("trades") - 1 do
local trade = getItem ("trades", i) -- получение таблицы данных из i-ой строки ТС
if bit.band(trade.flags, 4) == direction and trade.sec_code == SecCode and trade.datetime.hour >= 12 then -- сделка на продажу по конкр. инструменту
value = trade.value+value
end
end
return value
end
message ("Buy: " .. tostring (aggrF(0)))
message ("Sell: " .. tostring (aggrF(4)))
message ("Total: " .. tostring (aggrF(0)+aggrF(4)))
Пользователь
Сообщений: Регистрация: 27.01.2017
02.03.2021 19:09:22
То что получение данных таблицы сделано разово - это хорошо, т.к. это затратная по памяти функция. А вот то, что функция аггрегирования вызывается несколько раз - это не очень.
Почему не произвести расчет разово, перебрав сделки в одном цикле.
Что касается направления сделки, то если это обычная таблица trades (а не обезличенные сделки), то направление это 2-ой бит флага. И проверять его лучше логически через функцию bit.test, а не сравнивать с десятичным числом.
Николай, я предполагаю, что это вы мне написали, поэтому давайте объясню:
Цитата
А вот то, что функция аггрегирования вызывается несколько раз - это не очень. Почему не произвести расчет разово, перебрав сделки в одном цикле.
Если вы про вызовы в message, то это просто для демонстрации, чтобы человеку нагляднее было. Задачи что-то несколько раз перебирать и не стояло. Ему, вообще, только для лонга нужно было и, возможно, он один раз в конце дня этот скрипт запускает. Понятно, что одно и тоже несколько раз не нужно пересчитывать. Я также надеюсь, что он догадается при частом подсчете не обсчитывать строки таблицы каждый раз от 0 по новой при поступлении новой записи в таблицу.
Цитата
Что касается направления сделки, то если это обычная таблица trades (а не обезличенные сделки), то направление это 2-ой бит флага. И проверять его лучше логически через функцию bit.test, а не сравнивать с десятичным числом.
Да, 2-ой. И у меня 2-ой. Можно с префиксом "0x" поставить для наглядности: bit.band(trade.flags, 0x4). И bit.band в отличие от bit.test число возвращает. Почему bit.test лучше, чем bit.band - готов узнать.
Игорь М написал: Да, 2-ой. И у меня 2-ой. Можно с префиксом "0x" поставить для наглядности: bit.band(trade.flags, 0x4). И bit.band в отличие от bit.test число возвращает. Почему bit.test лучше, чем bit.band - готов узнать.
написал: Да, 2-ой. И у меня 2-ой. Можно с префиксом "0x" поставить для наглядности: bit.band(trade.flags, 0x4). И bit.band в отличие от bit.test число возвращает. Почему bit.test лучше, чем bit.band - готов узнать.
Кроме быстродействия и наглядности никаких.
В луа 5.3 есть битовые операции.
bit.band(trade.flags, 0x4)
можно заменить на
trade.flags & 0x4
Пасхалочка для Алексея Иванникова:
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 10:13:06
Nikolay, Какие уж тут, к чёрту, "быстродействие и наглядность"? Вместо одной ассемблерной команды - вызов функции, вместо угробленного типа INTEGER и красавцев-операторов типа &, | или >>= убожество с указанием номера бита...
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 10:14:29
, Да неужели?! И что, тип INTEGER ввели? А если нет, на кой всё это кастрированное убожество?
Пользователь
Сообщений: Регистрация: 30.01.2015
03.03.2021 11:02:59
Цитата
Владимир написал: s_mike@rambler.ru, Да неужели?! И что, тип INTEGER ввели? А если нет, на кой всё это кастрированное убожество
Чем больше визга, тем меньше элементарных знаний.
сначала нужно читать документацию, а потом выносить свое кастрированное убожество в форум
Пасхалочка для Алексея Иванникова:
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 11:09:26
, Ну так поменьше визжите. Тип INTEGER вернули [Y/N]? Ответить на вопрос способны, "чтец документации" [Y/N]? А если не вернули, см. мой предыдущий вопрос.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
03.03.2021 11:28:30
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 11:45:21
Старатель, Ха-ха-ха! А попробуйте сделать это же с переменной! Тем более, при этой долбаной "динамической типизации" и числовым типом NUMBER - ни int, ни float здесь не предусмотрены. В противном случае, не было бы хотя бы этой дурацкой "проблемы" с 19-значными номерами заявок и сделок.
Пользователь
Сообщений: Регистрация: 27.01.2017
03.03.2021 11:49:05
Владимир, я не очень понимаю в чем у Вас проблема с типами. Ее нет. Если Вы записываете в переменную значение другого типа, то это чья проблема? В других языках получите ошибку компиляции, здесь просто следите за руками.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
03.03.2021 11:53:20
Цитата
Владимир написал: А попробуйте сделать это же с переменной!
Что с переменной, что с константой, что с динамической типизацией, что без - результат всегда предсказуем. Если у вас что-то не получается, приведите конкретный пример. А то у вас, как всегда: "не читал, но осуждаю"
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 11:56:56
Nikolay, Да я уже тыщу раз говорил: я НЕ МОГУ записать в переменную значение какого-либо типа - это как уж моча в голову интерпретатору ударит. И это ПЕРВЫЙ попавшийся мне язык за мои 40 лет программирования, в котором уничтожен тип integer! Даже в JS, у которого тоже этот идиотский "тип var") он имеется!
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 12:01:23
Старатель, Да приводил уже, Господи! Почти сразу после моего появления здесь! Когда элемент брался по двойной индексации a=b[i[j]] тип был один, а если заменить на k=i[j];a=b[k] - другой.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
03.03.2021 12:06:50
Цитата
Владимир написал: Когда элемент брался по двойной индексации a=b[i[j]] тип был один, а если заменить на k=i[j];a=b[k] - другой.
Это не конкретный пример, а абстрактный, и не имеет смысла.
Скрытый текст
Цитата
Старатель написал: Что с переменной, что с константой, что с динамической типизацией, что без - результат всегда предсказуем.
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 27.01.2017
03.03.2021 12:08:32
Цитата
Владимир написал: , Да приводил уже, Господи! Почти сразу после моего появления здесь! Когда элемент брался по двойной индексации a=b[i[j]] тип был один, а если заменить на k=i[j];a=b[k] - другой.
Не бывает такого поведения. Если Вы между индексациями таблицы изменение значение переменной к, то язык здесь не виноват. В случае же первого варианта у Вас нет переменной и нет проблемы. Часто такое наблюдается при использовании глобальных переменных, когда к, объявленная в одном месте, перезаписывется в другом.
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 12:09:04
Старатель, Конкретный лень искать - покопайтесь сами в моих сообщениях, там подобных примеров было штуки три.
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 12:10:21
Nikolay, О, Господи! БЫВАЕТ такое поведение! Ладно, покопаюсь сам на досуге в своих записях - пока не до того...
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 12:11:33
Nikolay, Кстати, о птичках: проблема с типами была именно В ПЕРВОМ варианте, а во втором она исчезала,
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
03.03.2021 12:11:41
Цитата
Владимир написал: Конкретный лень искать - покопайтесь сами в моих сообщениях
Так это кому надо? У меня всё прекрасно с типами.
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 12:12:41
Nikolay, Ах, да - и переменные были локальные (те, которые индексы).
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 12:16:17
Старатель, Да и мне уже тыщу лет как не надо - я давным-давно "обвистовал" свой код конструкциями вида: i=j; -- компенсация глюка с переменной цикла или i=F; -- костыль от дебилизма с goto ::q:: -- метка аварийного выхода
Пользователь
Сообщений: Регистрация: 27.01.2017
03.03.2021 12:17:28
Владимир, неужели Вы думаете, что если бы такое было, то за все время существования языка (с 1993 года) это никто не заметил бы? Такого рода проблема (самопроизвольное магическим образом изменение значения переменной) - это просто крест на языке.
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 12:21:14
Nikolay, Именно эти слова я и говорил ТОГДА - почти дословно.
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 12:36:59
Старатель, Вот, чуток покопался, один из примеров (тот самый, про который я говорил): Значит, говорите, "a[i][1][1] должно быть числом а не строкой"? Допустим. А "j", простите, ЧЕМ должно быть после j=a[i][1][1]? Я ведь ему присваиваю именно СТРОКУ, если Вам верить! Так с какого же бодуна j вдруг оказывается ЧИСЛОМ, и message(i..": SP["..j.."]="..SP[j]) вдруг даёт правильный результат, а message(i..": SP["..a[i][1][1].."]="..SP[j]) - неправильный?
И ещё немного по глюкам - уже только ссылками:
Пользователь
Сообщений: Регистрация: 05.07.2019
03.03.2021 12:38:40
Коллеги, хочу немного уточнить по основному вопросу этой темы. Хочу для дальнейших расчетов использовать сделки (из таблицы Trades), которые прошли после определённого момента времени. В колонке "datetime" таблицы trades время каждой сделки указано в виде таблицы. Не знаю как сравнить эти табличные данные корректно с интересующим меня моментом времени. Решил табличные данные из datetime в trades переделать в секунды след образом и сравнивать уже секунды. сделал след образом
Код
os.time(getItem ("trades", i).datetime)
не получаю нужного результата. В чем косяк? Можно данные из колонки datetime в trades перевести в секунды или как по другому сравнить табличные данные с другим моментов времени ?
Пользователь
Сообщений: Регистрация: 27.01.2017
03.03.2021 13:14:28
Время лучше всегда и сравнивать в секундах, переведя его в unix-time, используя os.time. Надо определить переменную, определяющую время 12:00 текущего дня и сравнивать ее с временем таблицы. Условно: os.time(trade.datetime) > time_12
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
03.03.2021 13:45:21
Скрытый текст
Цитата
Владимир написал: Старатель , Вот, чуток покопался, один из примеров (тот самый, про который я говорил)
Вам в той теме объяснили вашу . Не вижу смысла повторяться. И динамическая типизация в данном случае вообще не при чём.
Цитата
Duke2 написал: как сравнить эти табличные данные корректно с интересующим меня моментом времени
Вариантов вагон, в зависимости от постановки задачи.
Код
if 100 * (100 * datetime.hour + datetime.min) + datetime.sec > 123000 then
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 13:55:14
Старатель, В той теме ошибка была НЕ моя, и связана она была именно с динамической типизацией. Ещё одна фраза по одной из приведённых ссылок: Да неужели? Не подскажете, почему же в моём примере a[i][1][1] - строка, а после j=a[i][1][1j вдруг оказывается ЧИСЛОМ? И почему добрая половина моих переменных, которые я ВСЕ ДО ЕДИНОГО заносил как строки вдруг оказываются числами?
Владимир написал: почему же в моём примере a[i][1][1] - строка, а после j=a[i][1][1j вдруг оказывается ЧИСЛОМ?
Если хотите конструктива, приводите минимальный код, который можно воспроизвести в консоли или квике. Иначе не нужно кричать об этом в каждой теме.
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 15:50:00
Старатель, Я уже приводил полный текст, уже тогда. Как именно я собирался обходить этот глюк с динамической типизацией (и как фактически обошёл) писал тогда же. Цитирую: И если вместо обычного описания int a; float b; string c; приходится ТАК извращаться, то это просто УБИЙСТВЕННАЯ характеристику языку! Кому и зачем это надо? Я уж лучше в момент записи данных в таблицы буду принудительно их заворачивать в tostring или tonumber (ещё не решил) и, при необходимости, "разворачивать" их в нужный тип в нужный момент. Если она И ПОСЛЕ ЭТОГО начнёт путать типы данных - это уже в морг.
написал: Да, 2-ой. И у меня 2-ой. Можно с префиксом "0x" поставить для наглядности: bit.band(trade.flags, 0x4). И bit.band в отличие от bit.test число возвращает. Почему bit.test лучше, чем bit.band - готов узнать.
Кроме быстродействия и наглядности никаких.
Какого быстродействия? Что быстрее bit.test или bit.band?
А попробовал! Между прочим, а почему Вы определяете тип с помощью math.type? Тем более, что ни типа integer, ни типа float в языке нет. Мне тут тысячекратно советовали "читать документацию", так в ней чёрным по белом написано: Тип значения, сохранённого в переменной, можно выяснить при помощи стандартной функции type. А теперь совсем смешно:
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 17:44:47
Старатель, Тычок в мегатонные доки? Хотел сразу отписать стандартное: "Читайте сами, раз уж ничего оттуда внятно процитировать не можете". Ну да ладно - пролистаем бегло на первый раз...
Ну так почитайте хотя бы представленную Вами документацию: 1. Lua is a dynamically typed language. This means that variables do not have types; only values do. 2. There are eight basic types in Lua: nil, boolean, number, string, function, userdata, thread, and table. 3. lua_Number. The type of floats in Lua. By default this type is double, but that can be changed to a single float or a long double. 4. Mathematical Functions. This library provides basic mathematical functions. It provides all its functions and constants inside the table math. 5. math.type (x). Returns "integer" if x is an integer, "float" if it is a float, or fail if x is not a number.
P.S. Врот именно, что "результаты ожидаемы"! Умножаем строку на число - этому придурку пофиг! Я и писал чёрте когда: Ну не делайте из меня идиота! я прекрасно знаю, что строка НЕ равно число! В моём коде индексы SP НЕ "заданы как числа", и я НЕ "пытаюсь обратиться к ним как к строкам". Я лишь ПРЕДПОЛАГАЮ, что раз уж эта антиллехтуальная сволочь не даёт мне возможность самостоятельно описать тип данных, то должна же она ХОТЬ ЧТО-ТО соображать! Я НЕ "использую числа а где-то строки" - Я НЕ ИМЕЮ ВОЗМОЖНОСТИ самостоятельно описать тип данных, а потому ВЫНУЖДЕН полагаться на антиллехт этого придурка! И у меня ВЕЗДЕ "однотипный способ получения данных" - код я Вам ПРИВЁЛ.
Bitwise operators, насколько я знаю, здесь вообще нет.
All other arithmetic operations applied to mixed numbers (integers and floats) convert the integer operand to a float - это нормально, но у нас-то была строка!
Ага, вот: "Several places in Lua coerce strings to numbers when necessary". Хренассе, "necessary"!
В общем, не хочу я больше даже читать про эту хрень. Текущая версия скрипта работает, как часы, и что она там куда преобразовывает - её проблемы.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
03.03.2021 19:42:27
Скрытый текст
Цитата
The type number represents both integer numbers and real (floating-point) numbers, using two subtypes: integer and float. Standard Lua uses 64-bit integers and double-precision (64-bit) floats
Код
local a = 0x7FFFFFFFFFFFFFFF
message(tostring(a)) -- 9223372036854775807 - signed int64
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 20:45:39
Старатель, Вы всё никак не успокоитесь? я же показал цитатами ИЗ ВАШЕЙ "документации", что Вы подменили понятия о типах данных конструкций языка типами данных библиотеки.По поводу последней цитаты - видел, повторяю: в языке НЕТ ни типа integer, ни типа float. Если бы они были, не было бы никакой проблемы с 19-значными кодами. И целочисленный тип вовсе не обязательно signed. Ещё 16 октября я писал: В 64-разрядный integer спокойно влезают даже 20-значные числа - более 18 квинтиллионов! Там работают ВСЕ 64 разряда до единого, и результат не округляется НИКОГДА! А теперь берём калькулятор в левую руку: 0xFFFFFFFFFFFFFFFF в десятичной системе счисления составит 18 446 744 073 709 515 615
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
03.03.2021 21:12:01
Скрытый текст
Документация не моя
Цитата
Владимир написал: Если бы они были, не было бы никакой проблемы с 19-значными кодами.
Напомните, какая проблема с 19-значными кодами в Lua 5.3 и 5.4?
Цитата
Владимир написал: целочисленный тип вовсе не обязательно signed
Здесь используется signed.
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 21:39:12
Старатель, Какая разница, какая версия Lua? Проблемы В ПРИНЦИПЕ не может быть при использовании unsigned int64! Вот при signed - МОЖЕТ быть, туда НЕ ВСЕ 19-значные числа влезают. И с какого бодуна "здесь используется signed"? Это то же самое число, которое отличается лишь интерпретацией его старшего бита: либо как знаковый разряд либо нет. А что там за проблемы - прочтите самую первую ветку в этом разделе. Лично я её даже не открывал - мне хватило только её названия: "Важно(!): Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок". Хренли там "поддерживать", программисты?
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
03.03.2021 22:19:07
Скрытый текст
Цитата
Владимир написал: А что там за проблемы - прочтите самую первую ветку в этом разделе. Лично я её даже не открывал
Отвечу вашими же словами:
Цитата
Владимир написал: "Читайте сами, раз уж ничего оттуда внятно процитировать не можете"
И не пишите о том, чего не знаете. То про Lua 5.1, и в первом же сообщении ветки это указано.
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
03.03.2021 22:35:30
Старатель, А мне незачем её читать - я и так знаю, что никаких проблем быть НЕ МОЖЕТ, причём НА ЛЮБОЙ версии в UI64 ЛЮБОЕ 19-значное число влезает с потрохами. Мой скрипт также прекрасно работает НА ЛЮБОЙ версии Lua, номера которых я не знаю и знать не хочу.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
04.03.2021 12:52:08
Скрытый текст
Цитата
Владимир написал: почему добрая половина моих переменных, которые я ВСЕ ДО ЕДИНОГО заносил как строки вдруг оказываются числами?
Цитата
Владимир написал: Ага, вот: "Several places in Lua coerce strings to numbers when necessary". Хренассе, "necessary"!
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
04.03.2021 13:15:42
Старатель, Очень самокритично, лапуль! Мне давно уже даже не смешно слышать стоны местных гуру по самым смехотворным проблемам. У нормальных программистов всё давно едет, а у вас... я уже не раз здесь говорил, что "дело было не в бобине".