агрегировать значения из таблицы сделок по временному условию

Страницы: 1
RSS
агрегировать значения из таблицы сделок по временному условию
 
Коллеги, добрый день.
Пытаюсь получить агрегированную сумму по 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  
 

Чуть подкорректировал (после 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)))
 
То что получение данных таблицы сделано разово - это хорошо, т.к. это затратная по памяти функция.
А вот то, что функция аггрегирования вызывается несколько раз - это не очень.

Почему не произвести расчет разово, перебрав сделки в одном цикле.

Что касается направления сделки, то если это обычная таблица trades (а не обезличенные сделки), то направление это 2-ой бит флага.
И проверять его лучше логически через функцию bit.test, а не сравнивать с десятичным числом.


if bit.test(trade.flag, 2) then
...
 
Цитата
Nikolay написал:
...
Николай, я предполагаю, что это вы мне написали, поэтому давайте объясню:

Цитата
А вот то, что функция аггрегирования вызывается несколько раз - это не очень.
Почему не произвести расчет разово, перебрав сделки в одном цикле.
Если вы про вызовы в message, то это просто для демонстрации, чтобы человеку нагляднее было. Задачи что-то несколько раз перебирать и не стояло. Ему, вообще, только для лонга нужно было и, возможно, он один раз в конце дня этот скрипт запускает. Понятно, что одно и тоже несколько раз не нужно пересчитывать. Я также надеюсь, что он догадается при частом подсчете не обсчитывать  строки таблицы каждый раз от 0 по новой при поступлении новой записи в таблицу.
Цитата
Что касается направления сделки, то если это обычная таблица trades (а  не обезличенные сделки), то направление это 2-ой бит флага.
И проверять его лучше логически через функцию bit.test, а не сравнивать с десятичным числом.
Да, 2-ой. И у меня 2-ой. Можно с префиксом "0x" поставить для наглядности: bit.band(trade.flags, 0x4). И bit.band в отличие от bit.test число возвращает. Почему bit.test лучше, чем bit.band - готов узнать.
 
Игорь М, Nikolay, Спасибо огромное! Очень помогли!
 
Цитата
Игорь М написал:
Да, 2-ой. И у меня 2-ой. Можно с префиксом "0x" поставить для наглядности: bit.band(trade.flags, 0x4). И bit.band в отличие от bit.test число возвращает. Почему bit.test лучше, чем bit.band - готов узнать.
Кроме быстродействия и наглядности никаких.
 
Цитата
Nikolay написал:
Цитата
Игорь М написал:
Да, 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
 
Nikolay, Какие уж тут, к чёрту, "быстродействие и наглядность"? Вместо одной ассемблерной команды - вызов функции, вместо угробленного типа INTEGER и красавцев-операторов типа &, | или >>= убожество с указанием номера бита...  :unamused:  
 
s_mike@rambler.ru, Да неужели?! И что, тип INTEGER ввели? А если нет, на кой всё это кастрированное убожество?
 
Цитата
Владимир написал:
   s_mike@rambler.ru, Да неужели?! И что, тип INTEGER ввели? А если нет, на кой всё это кастрированное убожество

Чем больше визга, тем меньше элементарных знаний.  

сначала нужно читать документацию, а потом выносить свое кастрированное убожество в форум  
 
s_mike@rambler.ru, Ну так поменьше визжите.  :wink:  Тип INTEGER вернули [Y/N]? Ответить на вопрос способны, "чтец документации" [Y/N]? А если не вернули, см. мой предыдущий вопрос.
 
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Старатель, Ха-ха-ха! А попробуйте сделать это же с переменной! Тем более, при этой долбаной "динамической типизации" и числовым типом NUMBER - ни int, ни float здесь не предусмотрены. В противном случае, не было бы хотя бы этой дурацкой "проблемы" с 19-значными номерами заявок и сделок.
 
Владимир, я не очень понимаю в чем у Вас проблема с типами. Ее нет. Если Вы записываете в переменную значение другого типа, то это чья проблема?
В других языках получите ошибку компиляции, здесь просто следите за руками.
 
Цитата
Владимир написал:
А попробуйте сделать это же с переменной!
Что с переменной, что с константой, что с динамической типизацией, что без - результат всегда предсказуем.
Если у вас что-то не получается, приведите конкретный пример. А то у вас, как всегда: "не читал, но осуждаю"  :lol:
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
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] - другой.
Это не конкретный пример, а абстрактный, и не имеет смысла.

Скрытый текст
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Цитата
Владимир написал:
Старатель, Да приводил уже, Господи! Почти сразу после моего появления здесь! Когда элемент брался по двойной индексации a=b[i[j]] тип был один, а если заменить на k=i[j];a=b[k] - другой.  
Не бывает такого поведения.
Если Вы между индексациями таблицы изменение значение переменной к, то язык здесь не виноват. В случае же первого варианта у Вас нет переменной и нет проблемы.
Часто такое наблюдается при использовании глобальных переменных, когда к, объявленная в одном месте, перезаписывется в другом.
 
Старатель, Конкретный лень искать - покопайтесь сами в моих сообщениях, там подобных примеров было штуки три.
 
Nikolay, О, Господи! БЫВАЕТ такое поведение! Ладно, покопаюсь сам на досуге в своих записях - пока не до того...
 
Nikolay, Кстати, о птичках: проблема с типами была именно В ПЕРВОМ варианте, а во втором она исчезала,  :wink:  
 
Цитата
Владимир написал:
Конкретный лень искать - покопайтесь сами в моих сообщениях
Так это кому надо? У меня всё прекрасно с типами.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Nikolay, Ах, да - и переменные были локальные (те, которые индексы).
 
Старатель, Да и мне уже тыщу лет как не надо - я давным-давно "обвистовал" свой код конструкциями вида:
i=j; -- компенсация глюка с переменной цикла
или
i=F; -- костыль от дебилизма с goto
::q:: -- метка аварийного выхода
 
Владимир, неужели Вы думаете, что если бы такое было, то за все время существования языка (с 1993 года) это никто не заметил бы? Такого рода проблема (самопроизвольное магическим образом изменение значения переменной) - это просто крест на языке.
 
Nikolay, Именно эти слова я и говорил ТОГДА - почти дословно.  :smile:  
 
Старатель, Вот, чуток покопался, один из примеров (тот самый, про который я говорил):
Значит, говорите, "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]) - неправильный?

И ещё немного по глюкам - уже только ссылками:
https://forum.quik.ru/messages/forum10/message48635/topic3419/#message48635
https://forum.quik.ru/messages/forum10/message48706/topic3419/#message48706
https://forum.quik.ru/messages/forum10/message49459/topic5872/#message49459
 
Коллеги, хочу немного уточнить по основному вопросу этой темы. Хочу для дальнейших расчетов использовать сделки (из таблицы 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
 
Скрытый текст


Цитата
Duke2 написал:
как сравнить эти табличные данные корректно с интересующим меня моментом времени

Вариантов вагон, в зависимости от постановки задачи.
Код
if 100 * (100 * datetime.hour + datetime.min) + datetime.sec > 123000 then
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Старатель, В той теме ошибка была НЕ моя, и связана она была именно с динамической типизацией. Ещё одна фраза по одной из приведённых ссылок:
Да неужели? Не подскажете, почему же в моём примере a[i][1][1] - строка, а после j=a[i][1][1j вдруг оказывается ЧИСЛОМ? И почему добрая половина моих переменных, которые я ВСЕ ДО ЕДИНОГО заносил как строки вдруг оказываются числами?
 
Скрытый текст
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Старатель, Я уже приводил полный текст, уже тогда. Как именно я собирался обходить этот глюк с динамической типизацией (и как фактически обошёл)  писал тогда же. Цитирую:
И если вместо обычного описания int a; float b; string c; приходится ТАК извращаться, то это просто УБИЙСТВЕННАЯ характеристику языку! Кому и зачем это надо? Я уж лучше в момент записи данных в таблицы буду принудительно их заворачивать в tostring или tonumber (ещё не решил) и, при необходимости, "разворачивать" их в нужный тип в нужный момент. Если она И ПОСЛЕ ЭТОГО начнёт путать типы данных - это уже в морг.
 
Цитата
Nikolay написал:
Цитата
Игорь М написал:
Да, 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.
А теперь совсем смешно:
Код
function main()
 local i;
 i=1;
 message("1. t="..type(i));   -- (number)
 i=1.1;
 message("2. t="..type(i));   -- (number)
 i="1";
 message("3. t="..type(i));   -- (string)
 i=i*1.1;
 message("4. t="..type(i));   -- (number)
 i="1.1";
 message("5. t="..type(i));   -- (string)
 i=i*1.1;
 message("6. t="..type(i));   -- (number)
 i=1;
 message("7. t="..math.type(i));   -- (integer)   
 i=1.1;
 message("8. t="..math.type(i));   -- (float)
 i="1";
 message("9. t="..math.type(i));   -- (attempt to concatenate a nil value)
end
 
Цитата
Владимир написал:
почему Вы определяете тип с помощью math.type?

Потому что у меня нет оснований не верить документации:
Цитата
math.type (x)
Returns "integer" if x is an integer, "float" if it is a float, or fail if x is not a number.

Цитата
Владимир написал:
А теперь совсем смешно
И что вас так забавляет? Все результаты ожидаемы.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Старатель, Тычок в мегатонные доки? Хотел сразу отписать стандартное: "Читайте сами, раз уж ничего оттуда внятно процитировать не можете". Ну да ладно - пролистаем бегло на первый раз...

Ну так почитайте хотя бы представленную Вами документацию:
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 НЕ "заданы как числа", и я НЕ "пытаюсь обратиться к ним как к строкам". Я лишь ПРЕДПОЛАГАЮ, что раз уж эта антиллехтуальная сволочь не даёт мне возможность самостоятельно описать тип данных, то должна же она ХОТЬ ЧТО-ТО соображать!
Я НЕ "использую числа а где-то строки" - Я НЕ ИМЕЮ ВОЗМОЖНОСТИ самостоятельно описать тип данных, а потому ВЫНУЖДЕН полагаться на антиллехт этого придурка! И у меня ВЕЗДЕ "однотипный способ получения данных" - код я Вам ПРИВЁЛ.
 
Цитата
Владимир написал:
пролистаем бегло на первый раз
Надо листать п. 3.4.3
 
Anton, Полистаем 3.4.3... :smile:

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"! :smile:

В общем, не хочу я больше даже читать про эту хрень. Текущая версия скрипта работает, как часы, и что она там куда преобразовывает - её проблемы.
 
Скрытый текст
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Старатель, Вы всё никак не успокоитесь? я же показал цитатами ИЗ ВАШЕЙ "документации", что Вы подменили понятия о типах данных конструкций языка типами данных библиотеки.По поводу последней цитаты - видел, повторяю: в языке НЕТ ни типа 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-значными номерами заявок и сделок". Хренли там "поддерживать", программисты?  :wink:  
 
Скрытый текст
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Старатель, А мне незачем её читать - я и так знаю, что никаких проблем быть НЕ МОЖЕТ, причём НА ЛЮБОЙ версии в UI64 ЛЮБОЕ 19-значное число влезает с потрохами. Мой скрипт также прекрасно работает НА ЛЮБОЙ версии Lua, номера которых я не знаю и знать не хочу.
 
Скрытый текст
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Старатель, Очень самокритично, лапуль! Мне давно уже даже не смешно слышать стоны местных гуру по самым смехотворным проблемам. У нормальных программистов всё давно едет, а у вас... я уже не раз здесь говорил, что "дело было не в бобине". :smile:  
Страницы: 1
Читают тему (гостей: 1)
Наверх