Система принятия решений и/или Нечеткая логика(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 написал:
А Не смущает то что мы ее задаем и вынуждены контролировать?
Для чего?
 
 
#725
13.02.2026 08:18:54
Цитата
VPM написал:
А вот это обидно! А Вы уберите sleep   и по рассуждаем чья инженерия кода лучше?
Sleep здесь вообще не важен. Тем более, что если уберете его из main, то Квик банально встанет, что не говорит в его пользу и организацию работы с потоками.
https://nick-nh.github.io/
https://github.com/nick-nh/qlua
 
 
#726
13.02.2026 14:59:11
Цитата
Nikolay написал:
Квик банально встанет, что не говорит в его пользу и организацию работы с потоками.
  В ветке "Что стоило бы изменить в QUIK по-крупному" (от 15.03.2024) предложены изменения схемы встраивания Lua в QUIK (с сохранением существующего API пользователя) устраняющие некоторые существующие его дефекты, но реакция разработчик QUIK нулевая. Нет даже возражений.
 
 
#727
15.02.2026 15:04:30
"Но если задача стоит построить систему, которая должна быть математически корректной, отказоустойчивой и масштабируемой, без событийной модели и формальных инвариантов не обойтись.
Потому что её поведение можно доказать на реальной торговле на любых объёмах и с любыми стратегиями, а не просто протестировать!" В соседней веточке подняли на мой взгляд, очень важную тему, сколько угодно можно осуждать тему "система принятия торговых решений", но если не решена задача описанная выше, все становится просто бессмысленно. Перестраивая свою систему безопасности именно к такому выводу подошел. И хочу привести ряд подходов.
 
 
#728
16.02.2026 10:56:38
Temporal Logic of Actions (TLA+) - метод, который взят за основу, — это не академическая теория, а активно используемая инженерная практика.

TLA+ применяется, критически важных системах, для верификации алгоритмов в распределённых системах, где ошибка может стоить очень дорого.
Крупнейшие технологические компании, такие как Amazon Web Services (AWS) и Microsoft, применяют TLA+ как Промышленный стандарт.
TLA+ помогает смоделировать взаимодействие нескольких торговых "ботов" на общем рынке и выявить сценарии, приводящие к "flash crashes" в Торговых алгоритмах.
Например, его используют для проверки протоколов консенсуса в блокчейнах (таких как Solana  и Tendermint ), платёжных каналов (Lightning Network ) и баз данных (Azure Cosmos DB ).

Суть. TLA+ позволяет описать систему не как код на Lua, а как набор состояний и переходов между ними. Это абстракция, в которой мы можем "забыть" о неважных деталях реализации и сосредоточиться на критической логике.

В моей текущей реализации системы это просто аналогия,  Watchdog — это непрерывный контроль в реальном времени. Он утверждает: "Прямо сейчас состояние допустимо".

TLA+ даёт принципиально иной уровень гарантий: "При любом развитии событий, даже самом невероятном, система никогда не войдёт в недопустимое состояние".
Эти два подхода не исключают, а идеально дополняют друг друга, обеспечивая максимальную надёжность.

Следовательно. Мы можем построить абстрактную модель системы на TLA+. Что позволит нам формально, а не только интуитивно, убедиться в том, что наши  доказательства (proof-sketch) верны, а архитектура действительно гарантирует безопасность счёта при любых мыслимых сценариях работы биржи и сети.

И это совершено иная концепция безопасности. "Ни гадать а быть уверенным"!
 
 
#729
22.02.2026 10:09:15
Нужно было просто  поправить  стратегию, и опять на те же "грабли!"

Разделение Ответственности.

Или взгляни на свою систему, как старший инженер, проектирующий инфраструктуру под множество стратегий, а не под одну конкретную. То есть, смещаемся на уровень инженера, который проектирует платформы, и отвечает за вопрос, как сделать правильное разделение ответственности.

Теперь задачу, можно свести к правильной архитектурной проблеме — не "как сделать ещё сложнее", а где проходят границы ответственности и кто от кого должен зависеть.
Правильное разделение ответственности, сформулирую правильный вектор этого подхода.

Напрашивается, разделение по типу ответственности:

A. Технологическое ядро (универсальное)
B. Адаптер к qLua (инфраструктура терминала)
C. Стратегический уровень (разные стратегии)

Вопрос стоит так, как избежать "Главной архитектурной ошибки", которая почти всегда возникает - слои смешаны, то есть:
* Стратегия знает про OrderManager;
* Recovery знает про FSM;
* FSM знает про детали брокера;
* Executor знает про стратегический контекст.
Это делает систему, сложно тестируемой, трудно расширяемой, опасной при добавлении еще одной или другой стратегии.


Сформулирую принципы, строго условно, выделив несколько слоев.

 Layer 1 — Технологическое ядро (Core Engine). Это НЕ про торговлю.
 
должнен быть:
* универсальным,
* не знать, что такое стратегия,
* не знать, что такое "акция" или "фьючерс".

Ему всё равно. Если завтра ты вставишь что то другое — ядро не меняется.

 Layer 2 — qLua Adapter Layer. Это тонкий слой интеграции.

за что отвечает:
* оборачивает getItem / getNumberOf
* обрабатывает OnTrade
* обрабатывает OnOrder
* делает sendTransaction
* нормализует данные

Это не стратегия. Это инфраструктурный адаптер. Ядро должно зависеть от интерфейса, а не от QUIK.

 Layer 3 — Strategy Layer.

Это единственный слой, где есть:
* SignalEngine;
* FSM арбитража;
* Логика входа/выхода;
* Крайние параметры (edge);
* Управление позицией

Стратегия НЕ должна, читать getItem, читать getNumberOf, знать class_code, знать brokerref. Она работает с абстракцией.

Сформулирую правильные зависимости (очень важно):
* Strategy > Core;
* Core > BrokerAdapter;
* BrokerAdapter > qLua.
И НИКОГДА наоборот.

"Стратегия не знает, что такое qLua. Core не знает, что такое конкретная стратегия".
 
 
Страницы: Пред. 1 ... 11 12 13 14 15
Читают тему
Техническая поддержка
+7 383 219 1606
© 2000–2026,
ARQA Technologies
Наверх