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

Владимир, Я уже говорил, чтоб говорить о великом нужно понятия сделать общими (говорить на одном языке и понимать о чем разговор).

Начну с начала. Вот из последнего от великих:Вас тут ничего не смущает?

Попробую пояснить что меня смущает. Уже неоднократно говорилось и разбиралось, что в луа единственная структура данных это таблица, таблица это половина ОПП,
а утверждение что этим не буду пользоваться, равно утверждению не понимаю как писать на луа!

или вот Мне можно ошибаться я пришел разбираться,  а тем кто тут самоутверждается  с закрытыми глазами, стоит глаза открыть!

VPM, Нет, у Glukator меня ничего не смущает. Более того, я подписываюсь почти под всеми его тезисами. Даже его подход с ключами-айдишками в стеке активных заявок заслуживает внимания, хоть я его и не принимаю. И я ещё в четвёртом своём комментарии на этом форуме 29.09.2020 10:31:16 писал: "В общем, с языком почти всё ясно: граф (точнее, дерево) объектов построить можно, а простейшую таблицу или даже массив - нельзя. Остаётся разобраться со строковыми переменными: способна ли эта loadstring интерпретировать строки как операторы языка (или, скажем, функции), то есть имеется ли здесь техническая возможность программирования данными."

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

VPM, Очереди создаются там, где они нужны. Очередь - это FIFO, независимо от технической реализации. А про Роберто Иерусалимского я всё сказал ещё тыщу лет назад, его примеры  меня не интересуют - и ему и им место на помойке. И всем фреймворкам там же.

Зачем эти общие слова, кому они нужны? Да и с вопросом я маленько разобрался.

А в чем здесь вопрос?
Первое это кодогенерация из произвольной строки. Второе прямое обращение к переменной. Естественно, что первое - это медленно, т.к. необходимо строку подготовить, скомпилировать текст в анонимную функцию и выполнить ее.

Я Вам советую изучить вопрос структур данных. Не в применении к языку Lua, а в общем. Языки разные, концепции одинаковые. Тогда у Вас отпадут многие вопросы по организации хранения, исполнения и т.д.
Форум это, конечно, хорошо, но фундаментальные знания получаются в библиотеке.

Это более сложный вопрос. Чаще всего с ним и работают, что вполне нормально для небольшого скрипта, выполняющего простые действия. А если скрипт - это десятки файлов и много строк, то так уже лучше не делать.
Причина банальна - очень легко допустить ошибку, переписав значение какой-то переменной. В этом плане, как я считаю, в Lua все должно быть наоборот - переменные должны быть локальными по смыслу, с блочной областью видимости. А глобальные создаваться специальным образом. Но как есть, так есть.

Поэтому я не использую глобальный контекст. Но его приходится использовать, если это методы и переменные из Qlua. Разработчики терминала все поместили в глобальный контекст. Поэтому и приходится к нему обращаться.
А для того чтобы это визуально различать и чтобы linter не выдавал ошибки, пишется _G, не более. Если бы интерфейс qlua был в библиотеке, например qlua, то было бы все лаконичней. Подключил библиотеку - получил методы и контекст терминала.

"Не в применении к языку Lua, а в общем", в общем мне не интересно, и зачем, дадут новый язык, буду с ним разбираться, а в луа структура данных это таблица, из которых все остальные строятся.
Да и пишу я строго для себя, а примеров на луа множество, вон игры как написаны!

Владимир,  Мы с Вами в своих подходах, пользуемся только луа, ну такой он, другого нет, так давайте подумаем что лучшее можно взять у него, как это эффективно можно применять!

Хвалюсь. На начала сессии  6.39%  Сейчас шорт, но не закрыт.
Подробности на графике.

VPM, Я уже давным-давно взял всё лучшее и эффективно применил.

Все будет зависеть где будет объявлена переменная А.
А так, конечно, можно. Но при этом надо не забывать, что эта А не будет видна в других файлах.А если нужна видимость, то чаще всего и решают это через глобальный контекст, что приемлимо, но значит, что это правильно. Хотя это субъективное понятие, конечно. Работает, устраивает, только для себя - значит правильно.

TGB, Если я ни чего не напутал, то подход максимальной локализации переменных, и по блочному их использованию, для таких пользователей как я оптимальный. И можно забыть про такое _G безболезненно для скрипта, поводом использования может я виться добиться необходимой видимости или есть еще повод?

Ага, а утверждение "не буду пользоваться молотком" тождественно "не понимаю, как забивать гвозди"?

Вы не читаете, что вам пишут, не воспринимаете аргументы, упрямо талдычите одно и то же про "профессора", "его пример", "демонстрацию приемов", описываете "возможности" и прочее, а потом еще и делаете логически ложные заявления (см. выше), объявляя их истинными. После чего обижаетесь, что кто-то здесь за ваш счет "самоутверждается" и вас не слушает.

Теперь к делу, о глобальных переменных. Вот, наберите в терминале lua пять строчек:Т. е., как вам уже раньше писал Nikolay, обращение через _ׂG[] - это просто еще один способ обращаться к переменным из глобального контекста. И способ на редкость уродливый. Запись x = 1 выглядит гораздо лучше, чем _G["x"] = 1. Так что не стоит заморачиваться на тему "что бы нам с этой таблицей эдакого сделать", есть она - и хрен с ней. Забудьте, для дела она не нужна ни вам, ни мне, ни кому бы то ни было еще.

VPM, я могу Вам предложить в качестве развлечения один проект https://github.com/kurapica/PLoop

Погрузитесь в крайнюю степень использования _ENV и все на чистом Lua.
Правда не ясно зачем, но, как говорится, красиво.

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

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

Один тут разумный человек - Glukator, Ну, я ещё.

Glukator,  Ну а это что по Вашему.Glukator,  Вы поймите я Вас не обидеть хочу, а показываю прямо то место где идет заблуждение, еще раз Луа  = таблица = ОПП, но если Вы используете таблицу , как можно можно не пользоваться ОПП, хотите Вы того или нет, мы эти пользуемся по умолчанию.

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

Посмотрел действительно все логично и просто:
Стек — это коллекция, элементы которой получают по принципу «последний вошел, первый вышел» (Last-In-First-Out или LIFO).
Это значит, что мы будем иметь доступ только к последнему добавленному элементу.

Очереди очень похожи на стеки. Они также не дают доступа к произвольному элементу, но, в отличие от стека, элементы кладутся (enqueue) и забираются (dequeue) с разных концов.
Такой метод называется «первый вошел, первый вышел» (First-In-First-Out или FIFO).
То есть забирать элементы из очереди мы будем в том же порядке, что и клали. Как реальная очередь или конвейер.

Прямо как складской учет.

Glukator, Да какие уж тут "конкретные практические задачи". Одни придурки разные идиотские предложения по модификации Квика пишут - видимо, это их стараниями системный софт настолько изуродован. Вторые годами микросекунды ловят, третьи за каким-то хреном до  _G и _ENV докопались, четвёртые без ОПП жить не могут (острый параноидальный психоз, штоле?), пятые load пытаются присобачить для доступа к переменным, шестым очередь фиксированного размера подавай, седьмым... при этом ни одна собака не может внятно сказать, ЗАЧЕМ им вся эта хрень нужна.

VPM, О, Господи! НА КОЙ в скрипте очереди? Кому, где, когда понадобилось соблюдение очерёдности обработки хранящихся там элементов? Только один из моих стеков организован строго по LIFO, и только потому, что АБСОЛЮТНО ПОФИГ, какой элемент сейчас обрабатывать, а проще стека ничего не бывает. А двум другим НЕ пофиг, новые элементы заносятся тоже строго на вершину стека, а вот выдернуть их обработчики могут ЛЮБОЙ из них - первый, последний или любой другой из середины. И, если это не последний, скидывают на освободившееся место последний и декрементируют размер стека. Всё настолько просто, что НУ НЕЧЕГО здесь обсуждать! .

Очередная брехня. ООП - это стиль организации кода, и ничего больше. Использовать этот стиль или другой - решает программист. В lua ООП прикручивается через жопу: надо городить свои конструкты для классов, наследования и прочего. И вовсе не "Луа = таблица = ООП", вовсе нет. И никаких "использований по умолчанию" нет и быть не может.
Вы сказали, что не имеете отношения к программированию и спросили совета у более опытных людей - вам его дали: не лезьте в эзотерику, используйте простые решения, не надо усложнять. А вы в ответ, нет уж, я сам решу, что мне надо, а вы мне тут давайте читайте лекции. У попа был двор, на двору кол, на колу мочало, начинаем все сначала.

Glukator,  Вы вроде хотели обсуждать торговые Задачи? ДА, за излишнею резкость извиняюсь.

Знание или не знания какого-то языка, ни как не влияют на умственные способности.
Про ОПП, на этих страницах я уже приводил авторов, выкладывал цитаты, откуда я делаю свой вывод. Если Вам нужно это оспорить обращайтесь к ним, со мной просто бессмысленно, либо приводите доводы опровергающие их утверждения.

Владимир,  Вы начинаете опять все запутывать, у стека есть четкое определение, при вашем подходе и очередь можно называть разновидность стека,
но ее называют очередью и дают четкое определение. Вот и двойная очередь оказывается широко известный подход.

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

"НУЖЕН КОНКРЕТНО В ВАШЕЙ ЗАДАЧЕ".
Я говорил что мне не нравится как моя программа обращается с памятью. Основная проблема это накопление массивов данных (в моем варианте таблиц).
Ну к примеру с частотой в 1 минуту получаю данные по свечам и индикаторам, складываю их в таблицу, которая за время сессии просто растет.
Для программы использующей портфель из тикеров, тайм фреймов, индикаторов(планирую переключаться между торговыми стратегиями внутри сессии) это расточительно!

Не знаю как назвать данный способ хранения но точно не стек, хоть и тарелочки из Вашего примера. Так как вся длинна этого массива не нужна (достаточно скажем 5 последних значения)
Нужен подход уменьшения количества элементов в таблицах  Я Вижу два подхода как организовать такую структуру:
1) После обработке 5 последних значений наставить nil;  bar[i][j][index-5].dec=nil;
2) Так как 1 вариант сильно похож на очередь то я вспомнил про двойную очередь из примера автора (которую не удалось обсудить и разобрать с первого поста)

И так задача сводится  к удобному универсальному методу уменьшения хранения данных в ОЗУ, по сути в моем представлении к организации ОЧЕРЕДИ!

Зато незнание базовых концепций ведет к неправильному пониманию смысла написанного. Вы нахватались цитат каких-то придурков, поняли их превратно, приняли свое неверное понимание за непреложную истину. Распинаться здесь, доказывая очевидные вещи (например, что lua НЕ является объектно-ориентированным языком), я не собираюсь - читайте книги (и не по lua, а по структурам данных в общем), поймете многое сами.
Ну вот опять... на колу мочало.
Непонятно, чем вас не устраивает самое простое и самое очевидное решение.

Если Вы будете удалять первый при удалении последнего,
то это называется  СДВИГОВЫЙ РЕГИСТР, а не очередь.

В очереди нет синхронизации извлечения первого и добавления последнего.
Такая синхронизация в сдвиговых регистрах.