Коллеги, добрый день. Пытаюсь получить агрегированную сумму по 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
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)))
То что получение данных таблицы сделано разово - это хорошо, т.к. это затратная по памяти функция. А вот то, что функция аггрегирования вызывается несколько раз - это не очень.
Почему не произвести расчет разово, перебрав сделки в одном цикле.
Что касается направления сделки, то если это обычная таблица 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 - готов узнать.
Nikolay, Какие уж тут, к чёрту, "быстродействие и наглядность"? Вместо одной ассемблерной команды - вызов функции, вместо угробленного типа INTEGER и красавцев-операторов типа &, | или >>= убожество с указанием номера бита...
s_mike@rambler.ru, Ну так поменьше визжите. Тип INTEGER вернули [Y/N]? Ответить на вопрос способны, "чтец документации" [Y/N]? А если не вернули, см. мой предыдущий вопрос.
Старатель, Ха-ха-ха! А попробуйте сделать это же с переменной! Тем более, при этой долбаной "динамической типизации" и числовым типом NUMBER - ни int, ни float здесь не предусмотрены. В противном случае, не было бы хотя бы этой дурацкой "проблемы" с 19-значными номерами заявок и сделок.
Владимир, я не очень понимаю в чем у Вас проблема с типами. Ее нет. Если Вы записываете в переменную значение другого типа, то это чья проблема? В других языках получите ошибку компиляции, здесь просто следите за руками.
Владимир написал: А попробуйте сделать это же с переменной!
Что с переменной, что с константой, что с динамической типизацией, что без - результат всегда предсказуем. Если у вас что-то не получается, приведите конкретный пример. А то у вас, как всегда: "не читал, но осуждаю"
Надо делать так, как надо. А как не надо - делать не надо.
Nikolay, Да я уже тыщу раз говорил: я НЕ МОГУ записать в переменную значение какого-либо типа - это как уж моча в голову интерпретатору ударит. И это ПЕРВЫЙ попавшийся мне язык за мои 40 лет программирования, в котором уничтожен тип integer! Даже в JS, у которого тоже этот идиотский "тип var") он имеется!
Старатель, Да приводил уже, Господи! Почти сразу после моего появления здесь! Когда элемент брался по двойной индексации a=b[i[j]] тип был один, а если заменить на k=i[j];a=b[k] - другой.
Владимир написал: Старатель, Да приводил уже, Господи! Почти сразу после моего появления здесь! Когда элемент брался по двойной индексации a=b[i[j]] тип был один, а если заменить на k=i[j];a=b[k] - другой.
Не бывает такого поведения. Если Вы между индексациями таблицы изменение значение переменной к, то язык здесь не виноват. В случае же первого варианта у Вас нет переменной и нет проблемы. Часто такое наблюдается при использовании глобальных переменных, когда к, объявленная в одном месте, перезаписывется в другом.
Старатель, Да и мне уже тыщу лет как не надо - я давным-давно "обвистовал" свой код конструкциями вида: i=j; -- компенсация глюка с переменной цикла или i=F; -- костыль от дебилизма с goto ::q:: -- метка аварийного выхода
Владимир, неужели Вы думаете, что если бы такое было, то за все время существования языка (с 1993 года) это никто не заметил бы? Такого рода проблема (самопроизвольное магическим образом изменение значения переменной) - это просто крест на языке.
Старатель, Вот, чуток покопался, один из примеров (тот самый, про который я говорил): Значит, говорите, "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]) - неправильный?
Коллеги, хочу немного уточнить по основному вопросу этой темы. Хочу для дальнейших расчетов использовать сделки (из таблицы Trades), которые прошли после определённого момента времени. В колонке "datetime" таблицы trades время каждой сделки указано в виде таблицы. Не знаю как сравнить эти табличные данные корректно с интересующим меня моментом времени. Решил табличные данные из datetime в trades переделать в секунды след образом и сравнивать уже секунды. сделал след образом
Код
os.time(getItem ("trades", i).datetime)
не получаю нужного результата. В чем косяк? Можно данные из колонки datetime в trades перевести в секунды или как по другому сравнить табличные данные с другим моментов времени ?
Время лучше всегда и сравнивать в секундах, переведя его в unix-time, используя os.time. Надо определить переменную, определяющую время 12:00 текущего дня и сравнивать ее с временем таблицы. Условно: os.time(trade.datetime) > time_12
Старатель, В той теме ошибка была НЕ моя, и связана она была именно с динамической типизацией. Ещё одна фраза по одной из приведённых ссылок: Да неужели? Не подскажете, почему же в моём примере a[i][1][1] - строка, а после j=a[i][1][1j вдруг оказывается ЧИСЛОМ? И почему добрая половина моих переменных, которые я ВСЕ ДО ЕДИНОГО заносил как строки вдруг оказываются числами?
Старатель, Я уже приводил полный текст, уже тогда. Как именно я собирался обходить этот глюк с динамической типизацией (и как фактически обошёл) писал тогда же. Цитирую: И если вместо обычного описания 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. А теперь совсем смешно:
Старатель, Тычок в мегатонные доки? Хотел сразу отписать стандартное: "Читайте сами, раз уж ничего оттуда внятно процитировать не можете". Ну да ладно - пролистаем бегло на первый раз...
Ну так почитайте хотя бы представленную Вами документацию: 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"!
В общем, не хочу я больше даже читать про эту хрень. Текущая версия скрипта работает, как часы, и что она там куда преобразовывает - её проблемы.
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
Старатель, Вы всё никак не успокоитесь? я же показал цитатами ИЗ ВАШЕЙ "документации", что Вы подменили понятия о типах данных конструкций языка типами данных библиотеки.По поводу последней цитаты - видел, повторяю: в языке НЕТ ни типа integer, ни типа float. Если бы они были, не было бы никакой проблемы с 19-значными кодами. И целочисленный тип вовсе не обязательно signed. Ещё 16 октября я писал: В 64-разрядный integer спокойно влезают даже 20-значные числа - более 18 квинтиллионов! Там работают ВСЕ 64 разряда до единого, и результат не округляется НИКОГДА! А теперь берём калькулятор в левую руку: 0xFFFFFFFFFFFFFFFF в десятичной системе счисления составит 18 446 744 073 709 515 615
Старатель, Какая разница, какая версия Lua? Проблемы В ПРИНЦИПЕ не может быть при использовании unsigned int64! Вот при signed - МОЖЕТ быть, туда НЕ ВСЕ 19-значные числа влезают. И с какого бодуна "здесь используется signed"? Это то же самое число, которое отличается лишь интерпретацией его старшего бита: либо как знаковый разряд либо нет. А что там за проблемы - прочтите самую первую ветку в этом разделе. Лично я её даже не открывал - мне хватило только её названия: "Важно(!): Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок". Хренли там "поддерживать", программисты?
Старатель, А мне незачем её читать - я и так знаю, что никаких проблем быть НЕ МОЖЕТ, причём НА ЛЮБОЙ версии в UI64 ЛЮБОЕ 19-значное число влезает с потрохами. Мой скрипт также прекрасно работает НА ЛЮБОЙ версии Lua, номера которых я не знаю и знать не хочу.
Старатель, Очень самокритично, лапуль! Мне давно уже даже не смешно слышать стоны местных гуру по самым смехотворным проблемам. У нормальных программистов всё давно едет, а у вас... я уже не раз здесь говорил, что "дело было не в бобине".