Система принятия решений и/или Нечеткая логика(FuzzyLogic)

Внимание

Для участия в обсуждениях и оформления подписки на новые сообщения форума вам необходимо зарегистрироваться.
Главная » Основные форумы » Программирование на языке Lua
Страницы: Пред. 1 ... 11 12 13 14 15
RSS
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
#701
09.02.2026 21:13:42
TGB,  Ну так это же просто двойная очередь, с которой я разбирался и только ленивый меня "по столу носом не возил". Более медленный вариант, чем скажем кольцевой буфер? Можете архитектуру привести или пример?
 
 
#702
09.02.2026 22:41:39
Цитата
VPM написал:
Более медленный вариант, чем скажем кольцевой буфер? Можете архитектуру привести или пример?
     Не надо. Большинству пользователям достаточно использовать приведенный простой вариант, по эффективности мало отличающийся от вашего кольцевого буфера, который я видел. Но кто хочет может использовать и ваш.
 
 
#703
09.02.2026 22:46:27
Цитата
VPM написал:
Ну так это же просто двойная очередь, с которой я разбирался и только ленивый меня "по столу носом не возил".
    Эта очередь разбиралась пользователем Старатель около 4-х лет назад. "Все украли до нас" :smile: .
 
 
#704
12.02.2026 10:11:30
Цитата
VPM написал:
это же просто двойная очередь, с которой я разбирался и только ленивый меня "по столу носом не возил". Более медленный вариант, чем скажем кольцевой буфер?
А что сравнивать, если они для разных задач предназначены?
Кольцевой буфер - для хранения ограниченного количества элементов. Индексация всё время сдвигается вправо. Возможно удаление и изменение элементов с любым индексом.
Очередь из сообщения #699 аналог обычной таблицы с индексацией, начиная с 1. Используется, когда надо удалять элементы в начале таблицы, т.к. table.insert с этой задачей плохо справляется.
 
 
#705
12.02.2026 10:20:52
Цитата
Йцукен написал:
table.insert
* table.remove
 
 
#706
12.02.2026 11:12:13
Цитата
Йцукен написал:
Кольцевой буфер - для хранения ограниченного количества элементов.
Так ведь и двойная очередь ограничена количеством элементов, для этого и храним первый и последний индекс. Лично меня всегда смущает в кольцевом буфере не явная индексации, "под ложечкой ноет" а тот ли элемент получен в расчетах. В то время как в двойной все линейно.
 
 
#707
12.02.2026 11:55:12
Я только не очень понял, почему представленный пример называется двойная очередь, если это просто очередь как связанный список.
И как она стала потокобезопасной в Lua, где этого нет.

Когда я говорил о двойной очереди, я говорил именно о двух очередях.
https://nick-nh.github.io/
https://github.com/nick-nh/qlua
 
 
#708
12.02.2026 13:20:29
Цитата
Nikolay написал:
Когда я говорил о двойной очереди, я говорил именно о двух очередях.
    Из написанного вами о двойной очереди (по сути реализующей одну) я не понял между какими функциональностями робота они могут использоваться и что при этом не обеспечивается в QLua, выложенным мной давно известным вариантом?
 
 
#709
12.02.2026 14:15:24
Цитата
Nikolay написал:
И как она стала потокобезопасной в Lua, где этого нет.
Добавление элемента в начало очереди в одном потоке не приводит к тому, что при попытке в другом потоке извлечь последний элемент возвращается nil.

Цитата
Nikolay написал:
Когда я говорил о двойной очереди, я говорил именно о двух очередях.
А можно ссылку на это обсуждение?
 
 
#710
12.02.2026 14:43:19
Цитата
Йцукен написал:
Добавление элемента в начало очереди в одном потоке не приводит к тому, что при попытке в другом потоке извлечь последний элемент возвращается nil.
Извлечь нет, а вот размер уже можно получить кривой. Плюс надо как-то гарантировать, что в двух потоках не будут разбирать очередь. Можно надеяться, что так не напишут, но это не гарантия, т.к. блокировок нет.
Хотя можно завернуть код в table.ssort

Цитата
Йцукен написал:
А можно ссылку на это обсуждение?
Это было не обсуждение, а просто комментарий, что иногда такой подход используют, когда порядок разбора очереди не столь важен.
https://nick-nh.github.io/
https://github.com/nick-nh/qlua
 
 
#711
12.02.2026 15:09:23
Цитата
Nikolay написал:
размер уже можно получить кривой.
Почему?
 
 
#712
12.02.2026 15:40:35
Цитата
Йцукен написал:
Почему?
Потому что в момент получения размера, другой поток изменит last или first

-- Текущий размер очереди ---
function QueueSize(self)    return self.last - self.first + 1  end
https://nick-nh.github.io/
https://github.com/nick-nh/qlua
 
 
#713
12.02.2026 15:56:33
Цитата
Nikolay написал:
Потому что в момент получения размера, другой поток изменит last или first
При обращении к элементу с индексом, равным размеру очереди вы не получите nil в любом случае. В этом смысле работа с очередью потокобезопасна, если запись только - в одном потоке, а извлечение - в другом.
Но, если вы одновременно добавляете элементы в разных потоках или извлекаете в разных потоках, то да, нужно код оборачивать в ssort, например.
 
 
#714
12.02.2026 16:15:32
Цитата
Nikolay написал:
в момент получения размера, другой поток изменит last или first
Не факт
 
 
#715
12.02.2026 16:20:07
Цитата
Йцукен написал:
Не факт
Да, но потокобезопасность - это гарантия, а не вероятность.
https://nick-nh.github.io/
https://github.com/nick-nh/qlua
 
 
#716
12.02.2026 16:38:33
Цитата
Nikolay написал:
Цитата
Йцукен написал:
Не факт
Да, но потокобезопасность - это гарантия, а не вероятность.
Я говорю, что сомнительно, что то, о чём вы пишите, вообще может произойти в Lua 5.4. Потому что там байт-код, который по определению выполняется под блокировкой.
 
 
#717
12.02.2026 16:59:55
Мы не знаем как реализовали доп. поток в Квик. Реализовали ли макросы lua_lock вместо заглушек в lua исходниках. Хотя в этой давней теме https://forum.quik.ru/forum10/topic3270/ обсуждалось, что таки реализовали.
https://nick-nh.github.io/
https://github.com/nick-nh/qlua
 
 
#718
12.02.2026 17:34:20
Nikolay, а для чего вам знать размер очереди? Вы же не извлекаете из середины?
Если организуется FIFO, то берётся первый элемент из очереди до тех пор, пока там что-то есть.
 
 
#719
12.02.2026 17:37:09
Цитата
Йцукен написал:
Nikolay, а для чего вам знать размер очереди? Вы же не извлекаете из середины?
Если организуется FIFO, то берётся первый элемент из очереди до тех пор, пока там что-то есть.
Может и не надо. Ремарка была, т.к. прозвучало, что это потокобезопасно. Не более.
https://nick-nh.github.io/
https://github.com/nick-nh/qlua
 
 
#720
12.02.2026 17:43:48
Цитата
TGB написал:
Из написанного вами о двойной очереди (по сути реализующей одну) я не понял между какими функциональностями робота они могут использоваться и что при этом не обеспечивается в QLua, выложенным мной давно известным вариантом?
Думаю, что для qlua такой проблемы вообще нет. Не те скорости. Это просто был пример для более тяжелых систем, не более.
https://nick-nh.github.io/
https://github.com/nick-nh/qlua
 
 
#721
12.02.2026 21:21:27
Цитата
Nikolay написал:
Думаю, что для qlua такой проблемы вообще нет. Не те скорости. Это просто был пример для более тяжелых систем, не более.
А вот это обидно! А Вы уберите sleep   и по рассуждаем чья инженерия кода лучше?
 
 
#722
12.02.2026 21:47:06
Или вот это, До обсуждались, про супер:
Цитата
Nikolay написал:
Nikolay , а для чего вам знать размер очереди? Вы же не извлекаете из середины? Если организуется FIFO, то берётся первый элемент из очереди до тех пор, пока там что-то есть.
А Не смущает то что мы ее задаем и вынуждены контролировать? Постоянно так Quik Ни чего нигарантирует?
 
 
#723
12.02.2026 21:56:16
Возможно термин не удачен "Двойная очередь",  но это просто перевод из учебника по луа от автора,  самого луа. Мне тоже кажется не правильно, поэтому применяю термин "Двухфакторная", более логина. Но раз закрепилась от автора  "Двойная очередь", то слов из песни не выбросить.
 
 
#724
12.02.2026 23:01:43
Цитата
VPM написал:
А Не смущает то что мы ее задаем и вынуждены контролировать?
Для чего?
 
 
Страницы: Пред. 1 ... 11 12 13 14 15
Читают тему
Техническая поддержка
+7 383 219 1606
© 2000–2026,
ARQA Technologies
Наверх