Очереди и двойные очереди в луа

Страницы: Пред. 1 ... 22 23 24 25 26 След.
RSS
Очереди и двойные очереди в луа, Пример из книги Р.Е.
 
nikolz, объясняльщик ты х**в, понятие "сдвиговый регистр" пришло в ЦОС из схемотехники, где оно материализуется в виде законченного устройства, в виде микросхемы, естественно, с ограниченным числом ячеек. А "очередь" - понятие чисто алгоритмическое, подразумевающее добавление элементов с одного конца, а извлечение с другого, вот и все. И по барабану, с какого там конца программист индексы нумерует. И то, что ему захотелось длину очереди ограничить - с алгоритмической точки зрения тоже ниего не меняет, кто раньше вошел - тот раньше вышел. Называй как хочешь, суть не меняется. Терминологии он тут решил поучить, ага.
 
Цитата
VPM написал:
Я Вам напомнил что, таблица в луа это половина ОПП! Или и это тоже не верно.
Половина не равна целому. Разве это не очевидно? ООП - это не только структура с методами.
Цитата
VPM написал:
1) Как оказалось есть разные варианты как выбрасывать:
сдвигать очередь (table.remove)?
Вызывать сборщик (nil);
Либо, как в двойной очереди контролировать индексы, пере присваивая значения.
Про table.remove() забудьте - это очень затратная операция. Пока ваша очередь будет относительно коротка - вы этого не заметите. Но если длина достигнет тысяч или десятков тысяч элементов - тормоза будут заметны невооруженным глазом.

Я поясню. При выполнении table.remove() элемент извлекается, а вот дальше происходит дичь - луа запускает цикл по перенумерации всех элементов, следующих после удаленного, и чем их больше, тем эта операция длится дольше. Поэтому - только хранить индексы первого и последнего элементов, и никак иначе. Удаленным элементам присваивать nil.
 
nikolz,  Вам нужно научиться отвечать на заданые Вам вопросы (ну хотябы так Да,Нет) для образованого, интелегеннтного человека это несложно, даже вежливо.
Вы погрузились сильно в тему "цифровой обработки сигналов" бывает.
В Программирование один сленг, в DSP другой, в торговле третий, еще есть арифметика... И здесь важно, чтоб друг друга понимали. А вот это не понятно
Цитата
nikolz написал:
Для экономии памяти очередь вообще не причем.
Как же не влияет?
 
Цитата
Glukator написал:
Удаленным элементам присваивать nil.
А что если просто перезаписывать, я про пример из 5 элементов?  nil будет вызывать сборщик, а перезапись ну поменял элемент объем остался прежним?
 
Цитата
VPM написал:
А что если просто перезаписывать, я про пример из 5 элементов? nil будет вызывать сборщик, а перезапись ну поменял элемент объем остался прежним?
Не очень понял, что перезаписывать? Если мы все еще про очередь (давайте для определенности положим, что мы добавляем элементы в конец, а извлекаем - с начала), то вариантов что-либо перезаписывать нет. При добавлении элемента - добавляем его, инкрементируем индекс конца очереди. При удалении - извлекаем первый элемент, присваиваем по его индексу nil, инкрементируем индекс начального элемента.  
 
VPM, Знание или незнание какого-то языка очень даже влияют на умственные способности. Есть даже выражение: "Сколько языков ты знаешь, столько раз ты человек". Только это говорится про ЗНАНИЕ языка, то бишь умение эти знания ПРИМЕНЯТЬ. А не как нынешние придурки: вызубрят пару сотен иностранных слов и, как говорил Крамаров, "могу переводчиком - английский я знаю".

С какой стати МЫ должны "обращаться к авторам", если их придурошные цитаты приводите ВЫ, да ещё и в СВОЕЙ ветке? Лично я бегло пролистал этого автора и тут же выбросил на помойку - с ним вообще не о чем говорить, он малограмотный дурак. А вот МЫ пытаемся вдолбить ВАМ этот медицинский факт. Но можем тоже послать - и к авторам, и куда подальше.

ДА ЧТО ВЫ ГОВОРИТЕ?! Полвека программирую, но первый раз слышу, что "у стека есть чёткое определение"! И где же это чудо существует? А ну, глянем в Вики: "Стек - абстрактный тип данных, представляющий собой список элементов, организованных по принципу LIFO". ЧО?! СТЕК - ЭТО СПИСОК?! Я не ослышался? Глаза мои меня не подводят?! Нет, чуть дальше тоже чёрным по белому: "В некоторых языках (например, Lisp, Python) стеком можно назвать любой СПИСОК, так как для них доступны операции pop и push".

Умница! При нашем (то бишь нормальном) подходе и очередью можно называть разновидность стека, Ибо стек, как и очередь, не только правила обработки его элементов, но и хранилище этих элементов, ожидающих обработки. Для залач торговли важно именно второе, и совершенно по барабану первое. И от того, что некоторые мои программы вытворяют со стеком, чтобы обеспечить возможность вызова любых функций с любым количеством и типом аргументов или вообще без них, он не перестаёт оставаться программным СТЕКОМ. И называть я буду что угодно и где угодно так, как Я считаю нужным и правильным.

Ну так и правьте ВАШУ программу - это ОНА как-то не так обращается с памятью. Моему скрипту памяти хватает - хоть жопой жуй! И как раз потому, что он НЕ накапливает никаких массивов данных, а просто торгует. К примеру данные по свечам он с получает с частотой раз в СЕКУНДУ, и ничего "за время сессии просто НЕ растёт". И делал он это, когда тестировался, для двадцати ТЫСЯЧ тикеров, а таймфреймов у него тогда было, кажется, 10 (сейчас 8). Так, может, "дело было не в бобине"? Кстати, хернёй с присвоением nil мой скрипт тоже не занимается.

Да-да, помню - кажется, nikolz тут утверждал, что торговый скрипт сложнее шахматной программы. Удачи в поиске сложностей! А для меня задача была и остаётся достаточно примитивной, потому-то она давно уже и реализована.
 
Цитата
Glukator написал:
Цитата
VPM написал:
А что если просто перезаписывать, я про пример из 5 элементов? nil будет вызывать сборщик, а перезапись ну поменял элемент объем остался прежним?
Не очень понял, что перезаписывать? Если мы все еще про очередь (давайте для определенности положим, что мы добавляем элементы в конец, а извлекаем - с начала), то вариантов что-либо перезаписывать нет. При добавлении элемента - добавляем его, инкрементируем индекс конца очереди. При удалении - извлекаем первый элемент, присваиваем по его индексу nil, инкрементируем индекс начального элемента.  
Я не просто про очередь, про двойную очередь из приведенного примера. Переписываются значения, а индексы либо увеличиваются либо уменьшаются в зависимости от варианта(Стек, очередь), структура таблицы остается равная 5 элементам. То есть потребление памяти стабильно, ну или меняется незначительно.  
 
Цитата
VPM написал:
А что если просто перезаписывать, я про пример из 5 элементов?  nil будет вызывать сборщик, а перезапись ну поменял элемент объем остался прежним?
  При перезаписи, если нет других ссылок на область памяти, то она будет удалена (почищена) мусорщиком. Под все данные, создаваемые непосредственно в Lua, память выделяется автоматически. Память, занимаемая неиспользуемыми (недостижимыми из скрипта) данными Lua, освобождается также автоматически (при сборке мусора).
 
Цитата
TGB написал:
Цитата
VPM написал:
А что если просто перезаписывать, я про пример из 5 элементов?  nil будет вызывать сборщик, а перезапись ну поменял элемент объем остался прежним?
   При перезаписи, если нет других ссылок на область памяти, то она будет удалена (почищена) мусорщиком. Под все данные, создаваемые непосредственно в Lua, память выделяется автоматически. Память, занимаемая неиспользуемыми (недостижимыми из скрипта) данными Lua, освобождается также автоматически (при сборке мусора).
Ну что получается мой поход не верен? Пусть массивы растут?
Хорошо вопрос  ставлю по другому как взять память под контроль чтобы за торговый день в 25 раз не росла?
 
 
Цитата
VPM написал:
 Я не просто про очередь, про двойную очередь из приведенного примера. Переписываются значения, а индексы либо увеличиваются либо уменьшаются в зависимости от варианта(Стек, очередь), структура таблицы остается равная 5 элементам. То есть потребление памяти стабильно, ну или меняется незначительно.  
Вы все еще про тот пример с List.pushlast(), List.pushfirst() ? Там ничего не остается постоянным. Сколько накидаете элементов, столько и будет. Там происходит ровно то же самое:
Цитата
Glukator написал:
При добавлении элемента - добавляем его, инкрементируем индекс конца очереди. При удалении - извлекаем первый элемент, присваиваем по его индексу nil, инкрементируем индекс начального элемента.  
Просто при добавлении элемента в начало очереди мы уменьшаем индекс начального элемента, вот и все. Он даже с успехом может стать отрицательным. А при удалении элемента с конца - по индексу конечного элемента присваивается nil, а индекс уменьшается на 1.
 
Написано:
Цитата
TGB написал:
При перезаписи, если нет других ссылок на область памяти, то она будет удалена (почищена) мусорщиком.
Это значит, что память расти не будет.
 
Glukator, А нафига присваивать ni?
 
Владимир, Вы опять все собрали в кучу, отсюда сумбур.
Ветка не моя, публикуются тут все, кому мало мальски интересны темы (я это никак не контролирую), просто также как все высказываюсь.
Если Вы не хотите чтоб с Вами дискутировал, не обращайтесь поименно со знаком вопроса. Мне к Вам не зачем обращаться все последние Ваши посты пустые. А пол века не показатель. Зачем к придуркам в вики, определения выложены на этой ветки от азов программирования. Раз не подверглись разбору то я делаю вывод правильные. Про Ваш чудо скрипт все наслышаны ни кто не видел но все знают, зачем одно и тоже повторять (без знака вопроса).
 
Владимир, чтобы мусорщик память почистил в конкретном этом примере с очередью. Есть у меня некое подобие очереди на свечах - прошлая, текущая, накапливаемая. На границе таймфреймов прошлой присваивается текущая, текущей - накапливаемая, а накапливаемая обнуляется. Понятно, что тут никаких присваиваний nil нафиг не надо, три арифметических операции и все дела. Но тут, насколько я могу понять, VPM пихает в очередь куда больше, чем 3 значения, ему это не подойдет :)
 
Цитата
TGB написал:
Написано:
Цитата
TGB написал:
При перезаписи, если нет других ссылок на область памяти, то она будет удалена (почищена) мусорщиком.
 Это значит, что память расти не будет.
Тогда хоть Вы поясните Очередь здесь применима как прием?
 
Цитата
Glukator написал:
Владимир, чтобы мусорщик память почистил в конкретном этом примере с очередью. Есть у меня некое подобие очереди на свечах - прошлая, текущая, накапливаемая. На границе таймфреймов прошлой присваивается текущая, текущей - накапливаемая, а накапливаемая обнуляется. Понятно, что тут никаких присваиваний nil нафиг не надо, три арифметических операции и все дела. Но тут, насколько я могу понять, VPM пихает в очередь куда больше, чем 3 значения, ему это не подойдет :)
Да хочу чтоб значения были переменной, ну к примеру для сглаживания достаточно три значения, для поиска паттерна нужно 30 и т.д.
 
Цитата
VPM написал:
Тогда хоть Вы поясните Очередь здесь применима как прием?
 Да.
 
Пробежался и так не понял в чем проблема, и причем здесь очередь.
Озвучена проблема роста памяти при расчете индикаторов. Ок.
Но для расчета индикаторов нужен банальный массив. Тупо для каждого индекса бара от 1 храним какое-то значение.
Пришел новый бар - записали данные по его индексу. Все. Но такой вариант - это постоянное увеличение хранимых данных.
Что можно сделать? Банально очищать неиспользуемые данные, присваивая nil. Правда помня, что перестанет работать #. Но это решается очень просто.
Сложнее - можно сделать массив фиксированного размера и записывать данные по кольцу. Так сделали разработчики терминала в последней версии примеров расчета индикаторов.
Что это дает - объем занимаемой постоянен и контролируем.

Зачем здесь очереди, стеки и др. списки - не ясно.
 
VPM, Нет, это Вы "всё собрали в кучу, отсюда сумбур". Автор ветки - Вы. А я всегда рекомендовал (и сам так делаю) пользоваться МИНИМАЛЬНО НЕОБХОДИМЫМ набором "технологических приёмов". А скрипт мой видели - те, кому я показывал. В частности, Борис прямо здесь писал, что он действительно справляется с 20К+ тикерами, и это он видел сам, находясь за тыщу километров от меня. Точнее, это видел только он - у меня нет в брокерах Финама, а у него есть. И ни у какого другого брокера столько тикеров вообще нет.

Glukator, А на кой НАМ беспокоиться о проблемах какого-то мусорщика? Давайте прикинем, ЧТО он вообще может чистить в НАШЕЙ задаче. При старте скрипта заглатываются все данные по тикерам, формируется дерево - свечи там разные и т.д. Эти данные СТАТИЧНЫ, там чистить нечего. Портфель тоже меняется НУ ОЧЕНЬ лениво. Что остаётся? Только те самые стеки. Теперь предположим, что скрипт наш отслеживает пару тыщ тикеров, и ВСЕМ им одновременно вдруг ударила моча в голову подать заявки. Размер стека резко подпрыгнул, обработчик за несколько минут его разобрал, и что имеем? Мусорщик думает, что наш стек занимает 2000 элементов, все они нам нужны, а скрипт знает, что там их лишь несколько штук или даже вообще ничего нет. При следующем всплеске активности скрипт просто перезабьёт новые данные в старые элементы - память под них уже выделена. А мусорщик сидит и молчит в тряпочку, а не путается под ногами. Сказка!
 
Nikolay,
Цитата
Зачем здесь очереди, стеки и др. списки - не ясно.
Чтобы буферизовать пиковые нагрузки. Забиваются по ситуации, а разгребаются спокойно по таймеру.
 
Цитата
Nikolay написал:
Пробежался и так не понял в чем проблема, и причем здесь очередь.
Озвучена проблема роста памяти при расчете индикаторов. Ок.
Но для расчета индикаторов нужен банальный массив. Тупо для каждого индекса бара от 1 храним какое-то значение.
Пришел новый бар - записали данные по его индексу. Все. Но такой вариант - это постоянное увеличение хранимых данных.
Что можно сделать? Банально очищать неиспользуемые данные, присваивая nil. Правда помня, что перестанет работать #. Но это решается очень просто.
Сложнее - можно сделать массив фиксированного размера и записывать данные по кольцу. Так сделали разработчики терминала в последней версии примеров расчета индикаторов.
Что это дает - объем занимаемой постоянен и контролируем.

Зачем здесь очереди, стеки и др. списки - не ясно.
А Вы можете на примере индикатора от разработчиков, показать места "массива фиксированного размера"?  Как это работает?
 
Цитата
Владимир написал:
При следующем всплеске активности скрипт просто перезабьёт новые данные в старые элементы - память под них уже выделена. А мусорщик сидит и молчит в тряпочку, а не путается под ногами. Сказка!
  Вы думаете, что если было выражение: tbl = {1, 2, 3} а вы потом вы написали еще раз tbl = {1, 2, 3}, то будет перезаписана область памяти из под первой таблицы?
 
TGB, Я не просто думаю - я в этом уверен! Только я никогда не писал "tbl = {1,
2, 3}" (кроме абсолютно статических данных),  я пишу tbl = {}, а уж потом tbl[1] = val и т.д.
 
Цитата
Владимир написал:
Nikolay,  
Чтобы буферизовать пиковые нагрузки. Забиваются по ситуации, а разгребаются спокойно по таймеру.

Да, но речь про расчет индикатора, с частотой максимум раз в 1 минуту. Если, конечно, самому не строить поток данных с меньшим интервалом, чего явно нет, раз используется DS.
даже если 100 сотня тикеров и десять индикаторов, то это не столь критично.
 
Цитата
VPM написал:
А Вы можете на примере индикатора от разработчиков, показать места "массива фиксированного размера"?  Как это работает?
Открываете пример MA.lua, например расчет SMA, и видите использование массива sum равного длине периода.
 
Цитата
Владимир написал:
TGB , Я не просто думаю - я в этом уверен!

Эксперимент в QLua (можете повторить):
tbl = {1, 2, 3}
message (tostring (tbl))  -- Результат: table: 0000024208D734F0 - это ссылка на таблицу --
tbl = {1, 2, 3}
message (tostring (tbl))  -- Результат: table: 0000024208D727F0 - это ссылка на другую таблицу --
----
Ваш стек это, наверняка, некоторая таблица, и вы туда пишите, наверное, не только числа, но возможно
строки и таблицы, которые вы где то создаете или получает. И строки и таблицы в Lua не перезаписываются.
Если есть сомнения, то можете в своем скрипте отключить мусорщик следующим образом: collectgarbage('stop')
чтобы под ногами не путался :smile: .
 
Nikolay,  Вот постановка
Цитата
VPM написал:
"НУЖЕН КОНКРЕТНО В ВАШЕЙ ЗАДАЧЕ".Я говорил что мне не нравится как моя программа обращается с памятью. Основная проблема это накопление массивов данных (в моем варианте таблиц).Ну к примеру с частотой в 1 минуту получаю данные по свечам и индикаторам, складываю их в таблицу, которая за время сессии просто растет. Для программы использующей портфель из тикеров, тайм фреймов, индикаторов(планирую переключаться между торговыми стратегиями внутри сессии) это расточительно! Не знаю как назвать данный способ хранения но точно не стек, хоть и тарелочки из Вашего примера. Так как вся длинна этого массива не нужна (достаточно скажем 5 последних значения)Нужен подход уменьшения количества элементов в таблицах  Я Вижу два подхода как организовать такую структуру:1) После обработке 5 последних значений наставить nil;  bar[j][index-5].dec=nil;2) Так как 1 вариант сильно похож на очередь то я вспомнил про двойную очередь из примера автора (которую не удалось обсудить и разобрать с первого поста)И так задача сводится  к удобному универсальному методу уменьшения хранения данных в ОЗУ, по сути в моем представлении к организации ОЧЕРЕДИ!
Это массив уже собирается в main()? С индикаторами нашли решения, зачистка лишнего в массивах. Дальше передали в main() хотим  выработать не которые правила.
Мой массив   выглядит так
Код
for i=1,#sec do ----  цикла по бумагам:
for j=1,#tf do   ---- Получаю Тек.index Свечей на всех tf:

Index[i][j]=DS[i][j]:Size()


td[i][j] = DS[i][j]:T( Index[i][j] ); 
bar[i][j][index].d = td[i][j] and get_date(td[i][j]) or nil;---- день один для разных тайфремов
bar[i][j][index].t = td[i][j] and get_time(td[i][j]) or nil;

bar[i][j][index].o = DS[i][j]:O( Index[i][j] ); 
bar[i][j][index].h = DS[i][j]:H( Index[i][j] );
bar[i][j][index].l = DS[i][j]:L( Index[i][j] );

---- ответ от индикатора тоже добавляю
bar[i][j][index].dec=nil;

Но потом добавил Проверку по индексу посчитал что сохранять значения свечей избыточно

Но массив растет  
 
Я не могу ничего ответить по показанной структуре, т.к. я не понимаю задачи. Например, зачем хранить данные баров, если они прекрасно получаются?
Можно предположить, что для более быстрого расчета индикатора, но и здесь вопрос, т.к. сам алгоритм индикатора может хранить все, что ему надо, контролируя объем хранимых данных.

В тех же примерах от разработчиков так и сделано. Есть экземпляр метода расчета, полученный через замыкание, хранящий все, что ему надо. Задача просто вызвать его для каждого бара, передав номер этого бара.
Прогнали на истории, а далее только при поступлении нового бара. И этот экземпляр расчета будет хранить данных столько, сколько надо для расчета и не более. Конечно, можно хранить данные начиная с индекса 1, но зачем, если для расчета надо всего три.
 
Nikolay, Да какая разница? Если буферизация предусмотрена и не востребована, размер буфера будет один элемент. А если вдруг эта "сотня тикеров" взбесится, тоже ничего страшного не произойдёт. А если не предусмотрена, то может и неприятность какая случиться.

TGB, Да нахера мне tbl = {1, 2, 3}? Это инициализация массива данными. В стеках же я инициализирую пары key-value. А стеки мои имеют разную структуру - от одного элемента до где-то десятка. И строки там есть, и мне насрать, что "строки и таблицы в Lua не перезаписываются" - я давным-давно это дело разбирал и показывал, что ДЛЯ МЕНЯ они перезаписываются.
 
Хранил данные баров для надежности так ка делал проверки (p0 = (Value(I, v_t, ds) or 0). Но сейчас добавил Проверку по индексу, посчитал что сохранять значения свечей избыточно.
Вы опять правы при этом подходе все можно решить через замыкание. Спасибо.
"А ларчик просто открывался" :lol:  
 
VPM,
Вам тут Виктор засрал мозги своей "гениальной" программой очереди.
Вот Вам тест, который доказывает, что ничего это творение не экономит.
Объясняю что делает тест.
Сначала в цикле загоняются push числа  в очередь и очередь увеличивается
Потом все числа выгоняются из очереди функцией pop и очередь становится вообще пустая
----------------
В процессе этого измеряем расход памяти до и после и запускаем сборщик чтобы собрать все что освободилось
вот сам тест:
Код
local M=10000000
local count1 = collectgarbage("count") -- получаем текущий размер памяти
print("начальный объем занятой памяти",count1);
--------------------------
local list=List.new()
for i=1, M do  List.pushlast(list,i) end
print("число элементов в очереди list после "..M.." циклов функции push="..#list)
local count1 = collectgarbage("count")
print("объем занятой памяти",count1);
--------------------------------
 for i=1, M do  List.popfirst(list) end
print("число элементов в очереди list после "..M.." циклов pop="..#list)
local count1 = collectgarbage("count")
print("объем занятой памяти после сборщика мусора",count1);
collectgarbage("collect")
local count1 = collectgarbage("count") -- получаем текущий размер памяти
print("объем занятой памяти после pop",count1);
------------------------------
collectgarbage("collect") -- выполняем сбор мусора
local count2 = collectgarbage("count") -- получаем размер памяти после сбора
print("объем занятой памяти после сборщика мусора",count1);

а это результат:
Код
>D:/lua53/lua53.exe -e "io.stdout:setvbuf 'no'" "Test_List.lua" 
начальный объем занятой памяти   63.69921875
число жлементов в очереди list после 10000000 циклов функции push=9999999
объем занятой памяти   262202.31738281
число элементов в очереди list после 10000000 циклов pop=0
объем занятой памяти после сборщика мусора   262202.51953125
объем занятой памяти после pop   262202.12792969
объем занятой памяти после сборщика мусора   262202.12792969
>Exit code: 0
Как видим, ничего не освободилось. НОЛЬ.
При этом элементов в очереди тоже ноль.
============================
Ты не поверь, Карл, такую чушь обсуждают целую неделю.
 
Цитата
TGB написал:
Написано:
Цитата
TGB написал:
При перезаписи, если нет других ссылок на область памяти, то она будет удалена (почищена) мусорщиком.
 Это значит, что память расти не будет.
Херня это  все
У вас очередь - это массив. Если в массиве хранятся числа, то для них не отводится дополнительной памяти.
Но даже если Вы храните указатель, то сам элемент массива останется в памяти. Запись nil - это запись 0 в тип элемента массива.
Элементы массива никуда не денутся пока Вы не уничтожите весь массив путем записи nil в его имя.  а не в его элементы.
 
Цитата
Glukator написал:
nikolz, объясняльщик ты х**в, понятие "сдвиговый регистр" пришло в ЦОС из схемотехники, где оно материализуется в виде законченного устройства, в виде микросхемы, естественно, с ограниченным числом ячеек. А "очередь" - понятие чисто алгоритмическое, подразумевающее добавление элементов с одного конца, а извлечение с другого, вот и все. И по барабану, с какого там конца программист индексы нумерует. И то, что ему захотелось длину очереди ограничить - с алгоритмической точки зрения тоже ниего не меняет, кто раньше вошел - тот раньше вышел. Называй как хочешь, суть не меняется. Терминологии он тут решил поучить, ага.
А ты тогда просто мудак.
Объясняю для тебя специально.
В цифровой обработке сигналов есть понятие элементы задержки. Эти понятия есть даже в ИИ. И это вполне алгоритмическое понятие в настоящее время, так как большинство разработчиков ИИ понятия не имеют о схемотехнике.  
Так вот , то что хочет автор этой темы реализуется не очередями и не стеками, а циклическими массивами.
-----------------------
Да и еще
Даже в луа есть операция сдвига вправо и влево - а это и есть сдвиговый регистр . можешь придумать другое название Мне по...
А то что Вы здесь херней занимаетесь это факт.
 
Цитата
nikolz написал:
Херня это  все
У вас очередь - это массив. Если в массиве хранятся числа, то для них не отводится дополнительной памяти.
Но даже если Вы храните указатель, то сам элемент массива останется в памяти. Запись nil - это запись 0 в тип элемента массива.
Элементы массива никуда не денутся пока Вы не уничтожите весь массив путем записи nil в его имя.  а не в его элементы.
  Вы до сих пор не поняли что?:
Цитата
TGB написал:
  1. Под все данные, создаваемые непосредственно в Lua, память выделяется автоматически. Память, занимаемая неиспользуемыми (недостижимыми из скрипта: для сильно непонятливых это области данных недоступные из него) данными Lua, освобождается также автоматически (при сборке мусора).
  2. Где вы у меня прочитали, что я пишу про элементы массива? Вы до сих пор не научились читать :smile: ?
  3. Запись nil - это не запись 0 в тип элемента массива, а запись в скрипте nil в поле массива. При такой записи элемент массива становится не доступным.
      Если умеете читать, то почитайте документацию на Lua.
  4. Заодно ответ на ваш вопрос в ветке об os.sysdate().  
      Ваша формула: local tim=60.*(60. * T.hour + T.min) + T.sec + 0.001*(T.ms + 0.001*T.mcs)
неправильная. Правильно: local tim=60.*(60. * T.hour + T.min) + T.sec + 0.001*(0.001*T.mcs)
 Давно бы распечатали результат вызова os.sysdate().
  os.sysdate() выдает таблицу о текущей дате в следующем виде:
  -- [day] (number) = 28
  -- [hour] (number) = 19
  -- [mcs] (number) = 719755 -- мкс. --- #### Это поле не является дополнением к полю ms
  -- [min] (number) = 46
  -- [month] (number) = 11
  -- [ms] (number) = 719 -- млс. --- ####
  -- [sec] (number) = 6
  -- [week_day] (number) = 2
  -- [year] (number) = 2023
 
Цитата
nikolz написал:

Херня это  все
У вас очередь - это массив. Если в массиве хранятся числа, то для них не отводится дополнительной памяти.
Но даже если Вы храните указатель, то сам элемент массива останется в памяти. Запись nil - это запись 0 в тип элемента массива.
Элементы массива никуда не денутся пока Вы не уничтожите весь массив путем записи nil в его имя.  а не в его элементы.
Это почти всегда так для массивов. Но и в этом случае есть особенности https://www.lua.org/gems/sample.pdf
Читаем раздел про таблицы.

Для текущей задачи, когда постоянно происходить увеличение числа элементов массива, в конечном итоге будет произведен shrink таблицы.
As a consequence, if you traverse a table erasing all its fields (that
is, setting them all to nil), the table does not shrink. However, if you insert some
new elements, then eventually the table will have to resize. Usually this is not
a problem: if you keep erasing elements and inserting new ones (as is typical in
many programs), the table size remains stable. However, you should not expect
to recover memory by erasing the fields of a large table: It is better to free the
table itself.

Но также там описан и грязный трюк по очистке. Kогда очень надо, то можно и воспользоваться.
 
nikolz,  Вот я поправил как хотел сделать на вашем примере. И Вот что получилось.
Код
local M=1000--0000
local count1 = collectgarbage("count") -- получаем текущий размер памяти
print("начальный объем занятой памяти",count1);
--------------------------
local list=List.new()
for i=1, M do  
List.pushlast(list,i)
print('Вставил', i, 'элемент ',  collectgarbage("count") )

if i>10 then print( 'Удалил первого', List.popfirst(list) , type(list), #list, collectgarbage("count") ) 
--local countI = collectgarbage("count")
end
end
print("число элементов в очереди list после "..M.." циклов функции push="..#list)
local count1 = collectgarbage("count")
print("объем занятой памяти",count1);
--------------------------------
-- for i=1, M do  List.popfirst(list) end
 
print("число элементов в очереди list после "..M.." циклов pop="..#list)
local count1 = collectgarbage("count")
print("объем занятой памяти после сборщика мусора",count1);
collectgarbage("collect")
local count1 = collectgarbage("count") -- получаем текущий размер памяти
print("объем занятой памяти после pop",count1);
------------------------------
collectgarbage("collect") -- выполняем сбор мусора
local count2 = collectgarbage("count") -- получаем размер памяти после сбора
print("объем занятой памяти после сборщика мусора",count1);
Вот ответ
Код
начальный объем занятой памяти   35.4248046875
List.pushlast: ; number; ; list.last=0; number; list[last]=1
Вставил   1   элемент    27.283203125
List.pushlast: ; number; ; list.last=1; number; list[last]=2
Вставил   2   элемент    27.404296875
List.pushlast: ; number; ; list.last=2; number; list[last]=3
Вставил   3   элемент    27.556640625
List.pushlast: ; number; ; list.last=3; number; list[last]=4
Вставил   4   элемент    28.677734375
List.pushlast: ; number; ; list.last=4; number; list[last]=5
Вставил   5   элемент    28.830078125
List.pushlast: ; number; ; list.last=5; number; list[last]=6
Вставил   6   элемент    28.951171875
List.pushlast: ; number; ; list.last=6; number; list[last]=7
Вставил   7   элемент    29.134765625
List.pushlast: ; number; ; list.last=7; number; list[last]=8
Вставил   8   элемент    29.255859375
List.pushlast: ; number; ; list.last=8; number; list[last]=9
Вставил   9   элемент    29.376953125
List.pushlast: ; number; ; list.last=9; number; list[last]=10
Вставил   10   элемент    29.5009765625
List.pushlast: ; number; ; list.last=10; number; list[last]=11
Вставил   11   элемент    29.751953125
Удалил первого   1   table   10   29.7802734375
List.pushlast: ; number; ; list.last=11; number; list[last]=12
Вставил   12   элемент    29.9052734375
Удалил первого   2   table   11   29.9345703125
List.pushlast: ; number; ; list.last=12; number; list[last]=13
Вставил   13   элемент    30.0595703125
Удалил первого   3   table   12   30.0888671875
......
Удалил первого   989   table   0   56.8974609375
List.pushlast: ; number; ; list.last=999; number; list[last]=1000
Вставил   1000   элемент    57.0283203125
Удалил первого   990   table   0   57.0576171875

число элементов в очереди list после 1000 циклов функции push=0
объем занятой памяти   57.1650390625
число элементов в очереди list после 1000 циклов pop=0
объем занятой памяти после сборщика мусора   57.263671875
объем занятой памяти после pop   28.4912109375
объем занятой памяти после сборщика мусора   28.4912109375
 
По моему Все четко работает!
 
Такая запись не корректна
print("число элементов в очереди list после "..M.." циклов функции push="..#list)
не работает  #list.
 
Который раз слышу вот это
Цитата
nikolz написал:
Так вот , то что хочет автор этой темы реализуется не очередями и не стеками, а циклическими массивами.
Уважаемые, не сочтите за труд, покажите на примере, как это делается в луа?
 
Цитата
nikolz написал:
В цифровой обработке сигналов есть понятие элементы задержки. <...> И это вполне алгоритмическое понятие в настоящее время
А ну-ка, покажи, где я утверждал обратное?
Цитата
nikolz написал:
Так вот , то что хочет автор этой темы реализуется не очередями и не стеками, а циклическими массивами.
Твой "циклический массив" если только под этим подразумевается аналог регистра сдвига - такая же очередь, только фиксированным числом ячеек памяти. Если хочешь, всякий "циклический массив" - это очередь, но не всякая очередь - "циклический массив".
Цитата
nikolz написал:
в луа есть операция сдвига вправо и влево - а это и есть сдвиговый регистр
Да ладно. Покажи?
Цитата
nikolz написал:
А то что Вы здесь херней занимаетесь это факт.
Так, да не совсем. Мы тут как раз-таки автору темы уже на протяжении 26 страниц (или сколько их там уже?!) пытаемся объяснить, что не надо заниматься херней.
Цитата
Владимир написал:
Glukator, А на кой НАМ беспокоиться о проблемах какого-то мусорщика?
<...> При следующем всплеске активности скрипт просто перезабьёт новые данные в старые элементы - память под них уже выделена. А мусорщик сидит и молчит в тряпочку, а не путается под ногами. Сказка!
Я об этом не подумал.  Пожалуй, надо будет вышвырнуть нахрен из скрипта очередь сделок и сделать вместо нее стек :)
Хотя потребляемая память и так не растет выше 2 Мб.
 
Цитата
VPM написал:
не работает  #list.
  Читайте документацию. Там написано, что операция # применима только для строк и таблиц-массивов (это такие, в которых индексы строго от 1 до N без пропусков).
 
Пример от nikolz,  оказал не оценимую помощь, помог разобраться в чем была путаница и не до понимание, помог собрать вариант который я объяснял.

Но прежде чем продолжить , должен извиница перед Владимир, Не чего не забыли, полвека показатель, по прежнему в строю на боевом коне знамя в руках.
А также поблагодарить всех кто принимал участие в обсуждении.

Ниже пример, то о чем пытался я сказать.
И что мы видим, реализован принцип LIFO  «последний вошел, первый вышел» (Last-In-First-Out или LIFO). Это вариант стека с помощью двусторонней очереди, не смотря на то что алгоритм называется двусторонняя очередь, собран СТЕК!  :shock:

Другую путаницу вносит название функции popfirst удаление первого, несмотря на то что операция называется удаление первого элемента, индекс первого элемента растет, отсекая как бы все то что осталось слева. Подтверждается все то что описал автор, в массив сохраняются значения индексов, получаем заданное количество элементов в которых храним значения, память под контролем, увеличение незначительно. Эффективность высокая.  Кто будет пробовать нужно поправить чтоб было как в моем примере.
function List.new()
  --return {first = 0, last = -1}
  return {first = 0, last = 0}
end
Код
local list=List.new()
local length=10; local M=1000--00--00
print("объем начального массива", M, "Кол. элементов в созданном length=",length);
local count1 = collectgarbage("count") -- получаем текущий размер памяти
------------------------------ LIFO
for i=1, M do 
 
print(i, ')','Начальные индексы', 'list.first =', list.first, '; list.last =', list.last )

List.pushlast(list,i)
print(i, ')','Вставил', 'index list.last =', list.last,'; присвоил значение элементa =',list[list.last], '(',collectgarbage("count"),')' )

if i>length then 
List.popfirst(list)
print( i, 'Операция - Удаление первого:', ')', 'присвоил индекс первоve элементу =', list.first, 'вернул значение первого элементa =', list[list.first] ,'(',collectgarbage("count"),')' ) --, list.first
end

end
print("LIFO (вариант реализации стека с помощью двусторонней очереди.) ----------------------");
print("начальный объем занятой памяти",count1);

print("число элементов в LIFO list после "..(M).." циклов функции рор=" ..(list.last-list.first))
local countOUT = collectgarbage("count")
print("объем занятой памяти",countOUT);
--------------------------------
collectgarbage("collect")
print("объем занятой памяти после сборщика мусора",collectgarbage("count"));
Вот ответ
Код
объем начального массива   1000   Кол. элементов в созданом length=   10
1   )   Начальные индексы   list.first =   0   ; list.last =   0
1   )   Вставил   index list.last =   1   ; присвоил значение элементa =   1   (   27.3759765625   )
2   )   Начальные индексы   list.first =   0   ; list.last =   1
2   )   Вставил   index list.last =   2   ; присвоил значение элементa =   2   (   28.4384765625   )
3   )   Начальные индексы   list.first =   0   ; list.last =   2
3   )   Вставил   index list.last =   3   ; присвоил значение элементa =   3   (   28.5166015625   )
4   )   Начальные индексы   list.first =   0   ; list.last =   3
4   )   Вставил   index list.last =   4   ; присвоил значение элементa =   4   (   28.5634765625   )
5   )   Начальные индексы   list.first =   0   ; list.last =   4
5   )   Вставил   index list.last =   5   ; присвоил значение элементa =   5   (   28.6728515625   )
6   )   Начальные индексы   list.first =   0   ; list.last =   5
6   )   Вставил   index list.last =   6   ; присвоил значение элементa =   6   (   28.7197265625   )
7   )   Начальные индексы   list.first =   0   ; list.last =   6
7   )   Вставил   index list.last =   7   ; присвоил значение элементa =   7   (   28.7666015625   )
8   )   Начальные индексы   list.first =   0   ; list.last =   7
8   )   Вставил   index list.last =   8   ; присвоил значение элементa =   8   (   28.8134765625   )
9   )   Начальные индексы   list.first =   0   ; list.last =   8
9   )   Вставил   index list.last =   9   ; присвоил значение элементa =   9   (   28.9853515625   )
10   )   Начальные индексы   list.first =   0   ; list.last =   9
10   )   Вставил   index list.last =   10   ; присвоил значение элементa =   10   (   29.0146484375   )
11   )   Начальные индексы   list.first =   0   ; list.last =   10
11   )   Вставил   index list.last =   11   ; присвоил значение элементa =   11   (   29.0625   )
11   Операция - Удаление первого:   )   присвоил индекс первоve элементу =   1   вернул значение первого элементa =   1   (   29.1484375   )
.........
1000   )   Начальные индексы   list.first =   989   ; list.last =   999
1000   )   Вставил   index list.last =   1000   ; присвоил значение элементa =   1000   (   51.08203125   )
1000   Операция - Удаление первого:   )   присвоил индекс первоve элементу =   990   вернул значение первого элементa =   990   (   51.109375   )

LIFO (вариант реализации стека с помощью двусторонней очереди.) ----------------------
начальный объем занятой памяти   26.5283203125
число элементов в LIFO list после 1000 циклов функции рор=10
объем занятой памяти   51.28125
объем занятой памяти после сборщика мусора   30.7470703125
Всем удачи еще раз спасибо за обсуждение! :smile:  
 
СВЕРШИЛОСЬ ЧУДО! На 25-й странице ветки один человек всё-таки понял, что хочет автор этой темы! Но, поскольку этот человек - nikolz, , остальным он это всё равно не сумеет рассказать, даже самому автору. Зато теперь ясно, что для того, чтобы автор получил то, что он хочет, ему нужен циклический массив. Что это за зверюга такая, Википедия не в курсе, я смутно припоминаю, что во времена моей молодости что-то похожее называлось "кольцевая очередь", а автору для решения своей проблемы наверняка потребуется ещё с полсотни страниц.
 
Ха-ха-ха! Только я отправил пост, что никто никогда не поймёт, что хочет автор, как увидел пост от автора, что он-таки понял! И что же он понял? МАМА ДОРОГАЯ! Оказывается, не "очереди и двойные очереди в луа", а "реализация принципа LIFO"! Оказывается, "с помощью двусторонней очереди собран СТЕК"! Ай да nikolz, ай да сукин сын! И как же прав Лавров: "Дебилы, б&я"!
 
Владимир,  Чему Вы радуетесь, если уж категорично то и Вы в этом списке!
Все что требовалось показать вот эти две записи:

---- по принципу «последний вошел, первый вышел» (Last-In-First-Out или LIFO)
Код
local lifo=List.new() List.pushlast(lifo,i) List.popfirst(lifo)
---- «первый вошел, первый вышел» (First-In-First-Out или FIFO)
Код
local fifo=List.new() List.pushfirst(fifo,i) List.popfirst(fifo)
Не знамя заберем :smile:  
 
VPM, Чему тут радоваться? Многодневному дебилизму? Кстати, что такое "циклический массив"? Потребовался? Вам тут тыщу раз говорили, что проще стека ничего нет, но Вам, оказывается, нужно было эту простейшую конструкцию реализовать непременно через жопу. Ну и как успехи?: Много памяти сэкономили? Хотя бы на КИЛОбайт наберётся?
 
Цитата
Владимир написал:
Много памяти сэкономили? Хотя бы на КИЛОбайт наберётся?
Ну зря Вы!
1) это модуль легко встроить в любую конструкцию, быстрая реализация основной идеи;
2) универсальность можно собрать и другие подходы кроме ФИФО и ЛИФО;
3) Эффективность за счет хранения массива индексов (Возможно есть и более эффективный варианты, кому нужно всегда можно заменить на свой) ;
4) размер новой таблицы легко устанавливается и меняется под задачу;
.......
n) Расход Памяти стабилизируется. Так как новая созданная таблица не растет.
Я этот пример доводил до 100 000 значений первоначального массива (~60-70 бар на М1 на фьючерсах). Все четко отработало.
Ответ очевиден сэкономили и не один КИЛОбайт!
 
VPM, Почему же зря? Я совершенно серьёзно спрашивал! Этот придурок постит разные "весёлые картинки", да крутит в своих дурацких тестах многомиллионные циклы. А здесь ОТКУДА они? Даже у меня скрипт контролирует СОТНИ тикеров, а у вас с николзом даже не десятки.

Мне насрать, что там куда "легко встроить". Встроили, наконец? Реализовали свою "основную идею"? Собрали "и другие подходы кроме ФИФО и ЛИФО"? А если и собрали, то ЗА КАКИМ ХРЕНОМ? И что ещё за "эффективность за счёт хранения массива индексов"? Я вот никаких индексов не храню, память на это не трачу - может, именно поэтому её у меня ДО МАМЫ, а вам, бедолагам, никогда ничего не хватает? И у меня не только "новая созданная", а ВАЩЕ НИ ОДНА таблица не растёт! И у меня ТРИ бара на таймфрейм, а на М1 вообще ни одного.
Ответ очевиден ПРОСРАЛИ и не один МЕГАбайт!
 
Владимир, Вы опять все с ног на голову, пример отличный от слова совсем! :smile:  почему уже сказано на свои вопросы я ответ получил!

То что вы сейчас описали, свой пример это подход частное решение - личное, я показал обще доступное решение которое с экономит массу времени тем кто только начинает кодить, и мне помог разобраться!
Есть  такой подход я его опишу словами из широко известного фильма "ЗА ДЕРЖАВУ ОБИДНО". А пользоваться этим или писать свое они разберутся без нас с Вами.

Ну и последнее не нужно к молодому поклонению применять дипломатические термины, как воспитали , чему научили то и получили.
 
Цитата
Владимир написал:
Всё, тема исчерпана, вопрос закрыт.
Страницы: Пред. 1 ... 22 23 24 25 26 След.
Читают тему
Наверх