VPM (Все сообщения пользователя)

Выбрать дату в календареВыбрать дату в календаре

Страницы: Пред. 1 2 3 4 5 6 7 8 9 10 11 ... 27 След.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Поле -* Свободно - Доступно для вывода средств при сохранении обеспеченности позиций либо открытия позиций по не маржинальным активам, с учетом заблокированных средств под активные заявки, с точностью валюты цены инструмента.

Соответствует значению параметра «НаПокупкуНеМаржин» в таблице «Клиентский портфель».

Для срочного рынка соответствует значению параметра «План. чист. поз.» в таблице «Ограничения по клиентским счетам».
параметр - lim_non_margin STRING Оценка денежных средств, доступных для покупки не маржинальных инструментов .

По факту - это средства доступные для торговли (для проведению торговых операций), А каково, как оформлено, судите сами?

Ну что тут скажешь, не в нашу копилочку талантов! Ну не специально же люди так старались?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Все о великом да о великом! А элементарные вещи: Как при торговле на маржинальном счете Акциями, получить "Свободный денежный остаток"? Во Задача!
Сколько лет уже пользуюсь QUIK но ответ на этот вопрос взывает смятение.
Элементарный вопрос для каждого, оценить капитал в распоряжении. Стоимость Активов в бумагах + Свободные денежные средства = Активы клиента.

Как получить Эти "Свободные денежные средства", без выкрутасов? Во Задача?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
TGB,  Вы в начале полностью прочитайте обсуждение, а затем рекомендации выдавайте. Если рассмотреть пример с фреймворком то он значительно легче, если подобную логику выстраивать подходом с замыканиями.

По образованию инженер тяжело расстаюсь с техникой. А мой еще хоть куда, даст фору некоторым что сегодня в продаже. Это лучшая пока машинка из всех что были у меня (Sony, Toshiba, Asus ..) хотя и 3 поколение i7 прекрасно справляется с 3 квиками 5 браузерами и еще всякой всячиной. Проблема есть с WiFi старое поколение ограничена скорость приема данных 200, а нужно 1000.  
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
TGB,  А Вам это о чем то говорит: ОС > Терминал > Lua? У Вас мощная машина, а у меня старенький 13 летний? 2. Еще в позапрошлом ВЕКЕ придумали "семафор" и он прекрасно справляется с пропусками поездов до сих пор. А пользоваться или нет параллельным программированием - решает пользователь для себя сам. Что касается меня так я примитивный пользователь - СЕМАФОР!  :smile:  
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Да, но в подходе с замыканиями - приходится вручную хранить состояние "этапа" в цикле "подожди, пока". А код постепенно превращается в "машину состояний". При добавлении новых этапов он становится всё громоздче и сложней. Отсюда и вывод для простых задач!

В подходе с корутинами. Никаких ручных "этапов" — код читается как обычный последовательный сценарий. Можно использовать yield где угодно, чтобы "заморозить" выполнение.  Можно легко добавить ожидание событий, сетевые операции и т.д. Логика выглядит линейно, но выполняется асинхронно.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
TGB,  Ну так это без тестов пoнятно конечно, чуть больше, т.к. стек корутины сохраняется.

Александр М, Да Вы правы, все так, по той же самой причине - стек корутины сохраняется! Данный пример с count, это простейшее действие, а корутину создаем для решения сложных, затратных задач, где нужно не зависимая от основного цикла обработка данных (фон). Так что довод не корректен, так как при решении сложной задачи будет нивелирован, а возможно и получен выигрыш (как в обсуждаемом примере с фреймворком).

Nikolay,  Ну как же нет? Смотрим на саму суть:

* Что делает замыкание? Создало локальную переменную.

* Что делает корутина? Создало независимы поток (без задержек и не блокирует QUIK с минимальной нагрузкой на CPU)

Преимущества очевидны:
1.  Не блокирует QUIK.
2.  Можно запустить много задач одновременно (мониторинг, логирование, анализ, обновление лимитов).
3.  Лёгкая расширяемая структура — можно добавлять задачи динамически.
4. Поддерживает интервалы выполнения (как cron).

Посмотрим, что такое «лёгкий поток» — coroutines (сопрограммы) в контексте Lua? Это кооперативные задачи, которые работают внутри одного потока исполнения, но могут приостанавливать и возобновлять выполнение, передавая управление вручную. yield() - приостанавливает только задачу, не весь скрипт.

По каким признакам это "лёгкий поток"?
1. Лёгкий по памяти. Корутине нужно всего несколько КБ стека.
2. Быстрый. Не создаёт системных потоков/контекстов.
3. Кооперативный. Поток сам решает, когда уступить управление.
4. Полный контекст исполнения. Сохраняются локальные переменные, состояние и позиция.
5. Пауза без блокировки QUIK. yield() приостанавливает только задачу, не весь скрипт.

* Каротину можно считать лёгким потоком Lua — она живёт, имеет собственный контекст и исполняется пошагово.
* А `main()` — просто планировщик, который возобновляет _ Ну так это без тестов пoнятно конечно, чуть больше, т.к. стек корутины сохраняется.

Резюме. В Lua корутины — это лёгкие, управляемые потоки. Они позволяют выполнять фоновую работу, не блокируя основной цикл QUIK. В QUIK это единственный безопасный способ организовать "многозадачность" без внешних библиотек.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Подсобрался с мыслями. Можно некий итог подвести.

Различия двух подходов, про применение см. выше мнение не поменял.

1. Подход с замыканием.
Нет возможности приостанавливать сложные задачи на середине выполнения.
Сложно реализовать ожидание событий или таймеров внутри задачи без внешнего кода.
Каждая задача должна сама заботиться о том, как уступать управление (через sleep в основном цикле).

2. Подход с корутиной.
Внутри корутины можно писать сложные алгоритмы и «разбивать» их на шаги.
Более гибкая модель.
Можно приостанавливать задачу на любом шаге.
Можно легко комбинировать несколько фоновых задач в одном цикле.
Более похоже на настоящие асинхронные потоки.
Сложнее.
Немного больше накладных расходов на создание и управление корутиной (хотя для QUIK это не критично).
coroutine.yield() - приостанавливает выполнение задачи, позволяя основному циклу выполняться и управлять её запуском.

Пока разбирались на кидал лёгкий планировщик фоновых задач для QUIK. Всем пока хорошего кода.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Ну хорошо вот другой пример:
Код
function main()
    threads[1] = coroutine.create(function() worker("A", 2) end)
    threads[2] = coroutine.create(function() worker("B", 5) end)

    while is_run do
        for _, co in ipairs(threads) do
            if coroutine.status(co) ~= "dead" then
                coroutine.resume(co)
            end
        end
        sleep(200)
    end
end
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Отличие прежнее.

Вы в потоке маин вызываете псевдоним функции выше, после выполнения функции цикл  приостанавливается sleep(1000) .
В то время как в примере с корутиной  имеется свой легки поток без задержек, а   coroutine.yield()  -- уступаем управление (подвешивает задачу) не создавая ни каких задержек, но цикл то маин выполняется. И таких задач можно вешать сколько угодно, в то время как в Вашем варианте после каждой задачи задержка.
Код
-- "Лёгкий поток" для фоновой задачиlocal function background_task()
    local count = 0
    while is_run do
        count = count + 1
        message("Фоновая задача: шаг " .. count)
        coroutine.yield()  -- уступаем управление
    end
end
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Да но есть ключевое отличие. yield() - приостанавливает только задачу, не весь скрипт как sleep.

--- Ключевая идея лёгкого потока (coroutine - кооперативная задача). Этот код создаёт лёгкий поток (фактически, сопрограмму), который выполняется по шагам, каждый шаг — между yield() и resume().
Код
local co = coroutine.create(function()
    for i = 1, 5 do
        print("Работаю...", i)
        coroutine.yield() -- приостанавливаем "поток"
    end
end)

while coroutine.status(co) ~= "dead" do
    coroutine.resume(co) -- возобновляем
    sleep(100)
end
Код
--- Пример «лёгкого фонового потока» в QUIK

local is_run = true

-- "Лёгкий поток" для фоновой задачи
local function background_task()
    local count = 0
    while is_run do
        count = count + 1
        message("Фоновая задача: шаг " .. count)
        coroutine.yield()  -- уступаем управление
    end
end

function main()
    local co = coroutine.create(background_task)
    message("Запуск фонового лёгкого потока...")
    while is_run do
        coroutine.resume(co)  -- возобновляем поток
        sleep(1000)           -- имитация "асинхронного" поведения
    end
end

function OnStop()
    is_run = false
    message("Остановка фонового потока.")
end


-- * Корутину можно считать лёгким потоком Lua — она живёт, имеет собственный контекст и исполняется пошагово.
 
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Нашел. Вот когда то я сохранял для себя понимание. Что то с родни Вашему подходу.

Lua предоставляет "лёгкие потоки" — coroutines (сопрограммы). Это кооперативные задачи, которые работают внутри одного потока исполнения, но могут приостанавливать и возобновлять выполнение, передавая управление.

--Ключевая идея лёгкого потока (coroutine)

local is_run = true
local threads = {}

function worker(name, delay)
   local i = 0
   while is_run do
       i = i + 1
       message(string.format("[%s] шаг %d", name, i))
       for _ = 1, delay do coroutine.yield() end
   end
end

function main()
   threads[1] = coroutine.create(function() worker("A", 2) end)
   threads[2] = coroutine.create(function() worker("B", 5) end)

   while is_run do
       for _, co in ipairs(threads) do
           if coroutine.status(co) ~= "dead" then
               coroutine.resume(co)
           end
       end
       sleep(200)
   end
end

function OnStop() is_run = false end

Это — мини-диспетчер потоков на чистом Lua.
Каждый "поток" (worker) — корутина с собственным ритмом, а цикл в main() играет роль планировщика.

* Корутину можно считать лёгким потоком Lua — она живёт, имеет собственный контекст и исполняется пошагово.

* А main() — просто планировщик, который возобновляет корутины.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
Nikolay написал:
А значит выполняться она может тоже только через вызовы в основном цикле mian. И тоже частота вызовов регулируется задержкой цикла main.Собственно ваш любимый hacktrade так и работает.
Вы не поняли сути hacktrade, как раз он как пример такой асинхронности.

1. При первом в ходе создается корутина и мы работаем в ее цикле, а у нее никаких задержек, (кроме накладных), в ней идет вся торговая логика расчеты, вычисление и так далее. Останавливаем исполнение когда выполнены условия на отправку заявки и заявка отправлена (выполняется yield).

2. Структурно код стал на выполнение в цикле маин (с задержками sleep)  функционально идет работа с заявкой. Где тут последовательность?
Самая что не на есть асинхронность.

Выполнение кода структурно разделено на две составляющие:
А) Поиск условия выполнения заявки (в цикле корутины);
Б) Не посредственное исполнение заявки (взаимодействие с апи квик - в цикле маин).  
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Смотрим внимательно, сравниваю эти два подхода.

На первый взгляд оба примера — "фоновые циклы" в QUIK, но они не эквивалентны и не взаимозаменяемы?

Это разные подходы к организации фоновой работы:

Вариант 1 — "корутина как фоновый поток".

local co = coroutine.create(worker)
while is_run do
   coroutine.resume(co)
   sleep(1000)
end

Вариант 2 — "итераторы (замыкания) как фоновые задачи".

local worker1 = counter(1, 5, print)
local worker2 = counter(2, 20, print)

while is_run do
   if worker1 and worker1() then worker1 = nil end
   --...
   sleep(100)
end

Различие по сути:

| Критерий                     | Вариант 1 (корутина)                 | Вариант 2 (итераторы/счётчики) |
| ----------------------------     | ------------------------------------       | ------------------------------     |
| Тип выполнения               | Асинхронное (через yield)            | Синхронное (через цикл)        |
| Внутреннее состояние         | Контекст сохраняется автоматически   | Состояние хранится в замыкании |
| Можно делать yield внутри    | Да                                   | Нет                            |
| Можно использовать sleep()   | Только в main, не в worker           | В основном цикле               |
| Уровень сложности            | Средний                              | Простой                        |
| Производительность           | Чуть выше накладных вызовов          | Зависит от частоты цикла       |
| Где применять                | Долгие фоновые задачи                | Мелкие периодические проверки  |

Вывод. Не взаимозаменяемы!

 Первый вариант — "реальный фон через корутину" (асинхронная модель).
 Второй — "упрощённый псевдопараллельный цикл" (итераторы).
 
Мнение.

1. Если нужно имитировать многопоточность (параллельно опрашивать QUIK, считывать данные и т.п.) -> вариант с корутиной.
2. Если просто нужно выполнять несколько лёгких задач с разной частотой -> вариант с замыканиями/итераторами.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Нет, дело тут не в счетчике, счетчик в моем примере это просто минимальная операция для примеров. Дело в этом:
Цитата
Nikolay написал:
Вместо теста скорости можно вставить любую периодическую задачу: * запрос рыночных данных (getParamEx), * обновление таблиц QUIK, * контроль позиций и алертов, * логирование в файл.и так далее.
Корутина  превращает прямолинейную реализацией - последовательное чтение функций, в не линейное исполнение разных задач. В едином потоке луа появляется, как бы несколько раздельно выполняемых задач. Мы же можем к сопрограммам написать и менеджер, по их управлению.  
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
Nikolay написал:
Корутина с остановкой удобна, если надо запомнить состояние и вернуться к выполнению
Так это и есть ключ. Помнит место остановки и туда возвращается. Если подобное исполнение делать с помощью функции, нужно что то наверное в парадигме машины состояний. А затем придется еще этим состояниями управлять.

По чему мне нравится подход с корутинами. Логику можно строить так, как мы с Вами это сейчас обсуждаем. Вот прямо могу написать код обсуждения, асинхронно получить время, послушать новости, и еще чего то там. Мне кажется круто!
Кстати навело на мысль попробовать в отдельной корутине отслеживать состояние ордеров, сейчас двух факторная по транс ид и номеру ордера из колбеков, а что если не зависимо все подтвердили тогда только учитываем? Попробую.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Дело тут не в терминологии, а в особенностях применения сопрограмм в Lua, и те возможностях которые возникают от их применения. Исполнять код по принципу "который нужно, когда нужно"!  
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Вот и Вы туда же? Цель:
Цитата
VPM написал:
сделать фоновый поток в QUIK с использованием корутины, без блокировки терминала и с периодическим выводом результата.
Скорость ограничена скорость получения данных, "Не прыгнешь выше своей головы":
Цитата
VPM написал:
И главное здесь, сама система: "Биржа - Сервер - Терминал - Скрипт"
Измерение скорости в наших условиях для наших задач, нужно только для оптимизации скрипта.  А у нашего "Профессора", идет путаница, он пытается обрабатывать большие массивы, где безусловно важным факторам является скорость операций, с нашими повседневными задачами, ограниченными по скорости передачи данных. Это и пытаюсь донести, обижается?  :sad:    Насчет смысла, смыл писать эффективный код, как же нет?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Nikolay,  На примере код TGB,  выложил два простых скрипта, различных по своей архитектуре. Приведите пример Вашего подхода, возможно он действительно будет оптимальной и лучше? Я ведь на самом то деле, ни чего не отрицаю и ни утверждаю, а декларирую возможности Lua,  и возможности создавать шедевры. Давайте сравним, всем будет интересно! Возможно я заблуждаюсь?  
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Ну и последнее. Для Профессора и не только.

Приведу пример, как сделать фоновый поток в QUIK с использованием корутины, без блокировки терминала и с периодическим выводом результата.

--- Цель. Скрипт main() должен:

* стартовать и создать фоновый поток,
* этот поток будет каждые несколько секунд выполнять тест,
* не блокировать работу QUIK,
* безопасно завершаться при остановке скрипта.
Код
--- Рабочий пример фонового скрипта QUIK с корутиной
local is_run = true  -- глобальный флаг для остановки фоновой задачи

function main()
    message("Скрипт запущен. Идёт фоновое измерение производительности...")

    -- создаём корутину (фоновую задачу)
    local co = coroutine.create(worker)

    -- основной цикл QUIK
    while is_run do
        local ok, err = coroutine.resume(co)
        if not ok then
            message("Ошибка в корутине: " .. tostring(err))
            break
        end
        sleep(1000) -- основной поток спит 1 сек между циклами
    end

    message("Скрипт остановлен.")
end

-- фоновая функция
function worker()
    local N = 100000
    local c, f = 0, 0

    local function foo()
        f = f + 1
    end

    local co_task = coroutine.create(function()
        while true do
            c = c + 1
            coroutine.yield()
        end
    end)

    while is_run do
        local TT1 = os.clock()
        for i = 1, N do
            local ok, err = coroutine.resume(co_task)
            if not ok then
                message("Ошибка в co_task: " .. tostring(err))
                break
            end
        end
        TT1 = (os.clock() - TT1) * 1000

        local TT2 = os.clock()
        for i = 1, N do
            foo()
        end
        TT2 = (os.clock() - TT2) * 1000

        local out = string.format(
            "Фон: N=%d, coroutine=%.3f мс (c=%d), func=%.3f мс (f=%d), T1/T2=%.2f",
            N, TT1, c, TT2, f, TT1 / TT2
        )
        message(out)

        sleep(3000) -- измерение каждые 3 секунды
    end
end

function OnStop()
    is_run = false
    message("Останавливаем фоновую задачу...")
end

Вывод:
   TYPE   DATE   TIME   MESSAGE
1   1   29.10.2025   10:31:19   Скрипт запущен. Идёт фоновое измерение производительности...
2   1   29.10.2025   10:31:20   Фон: N=100000, coroutine=584.000 мс (c=100000), func=6.000 мс (f=100000), T1/T2=97.33
3   1   29.10.2025   10:31:23   Фон: N=100000, coroutine=604.000 мс (c=200000), func=7.000 мс (f=200000), T1/T2=86.29
4   1   29.10.2025   10:31:27   Фон: N=100000, coroutine=586.000 мс (c=300000), func=7.000 мс (f=300000), T1/T2=83.71
5   1   29.10.2025   10:31:30   Фон: N=100000, coroutine=553.000 мс (c=400000), func=7.000 мс (f=400000), T1/T2=79.00
6   1   29.10.2025   10:31:34   Фон: N=100000, coroutine=614.000 мс (c=500000), func=7.000 мс (f=500000), T1/T2=87.71
7   1   29.10.2025   10:31:38   Фон: N=100000, coroutine=550.000 мс (c=600000), func=7.000 мс (f=600000), T1/T2=78.57
8   1   29.10.2025   10:31:41   Фон: N=100000, coroutine=555.000 мс (c=700000), func=7.000 мс (f=700000), T1/T2=79.29
9   1   29.10.2025   10:31:45   Фон: N=100000, coroutine=544.000 мс (c=800000), func=6.000 мс (f=800000), T1/T2=90.67
10   1   29.10.2025   10:31:45   Останавливаем фоновую задачу...
11   1   29.10.2025   10:31:49   Скрипт остановлен.
--- Как это работает:

| Часть       | Что делает                                                                                                                                         |
| ------------  | ---------------------------------------------------------------------------------------- ------------------------------------------|
| main()      | Запускается QUIK ом. Создаёт и запускает корутину worker().                                                      |
| worker()   | Основная логика теста — циклически выполняет измерения и выдаёт результат в message(). |
| sleep()     | Позволяет не блокировать интерфейс и экономит CPU.                                                                 |
| OnStop() | Срабатывает при остановке скрипта пользователем — корректно завершает цикл.                    |

--- Что можно делать в фоне?

Вместо теста скорости можно вставить любую периодическую задачу:
* запрос рыночных данных (getParamEx),
* обновление таблиц QUIK,
* контроль позиций и алертов,
* логирование в файл.
и так далее.

Корутины в QUIKэто идеальный инструмент для таких сценариев, они позволяют делать "псевдопотоки", не мешая интерфейсу и другим скриптам!!!

Это и есть основной смысл и задача Корутин в QUIK! Надеюсь убедил? Всем хорошего кода.  :smile:  
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Помним!
Время работы корутин в QUIK может зависеть от множества факторов:
* нагрузки платформы,
* количества исполняющихся скриптов,
* задержек в сети
и так далее.

Код
--[[Помним!
Время работы корутин в QUIK может зависеть от множества факторов: 
* нагрузки платформы, 
* количества исполняющихся скриптов, 
* задержек в сети
 и так далее.
--]]

-- Переписанный пример с использованием корутин и пустой функции в QUIK в формате кода Lua:

--local message = message or print;
local run = true

function main()

   local N = 100000
   local c,f = 0,0
   -- создаем корутину, которая будет выполнять асинхронную задачу
   local co = coroutine.create(function()
      local yield = coroutine.yield
      while true do
         -- можно выполнять любую логику
       c = c + 1
         yield()  -- здесь задача будет приостанавливаться
      end
   end)

   -- простая функция, которая ничего не делает
   local function foo1() 
        f = f + 1
        return f
   end

   local out = 'Результат теста: количество вызовов = ' .. N .. ', время вызова сопрограммы '
   while true do
        
      -- замер времени для корутины
        local TT1 = os.clock()
        for i = 1, N do
            local ok, err = coroutine.resume(co)  -- возобновляем выполнение корутины
            if not ok then
                message("Ошибка при выполнении корутины: " .. err)
                break
            end
        end
        TT1 = (os.clock() - TT1) * 1000
      message("TT1: " .. TT1 .."; c = " .. c)

        -- замер времени для обычной функции
        local TT2 = os.clock()
        for i = 1, N do
            foo1()
        end
      TT2 = (os.clock() - TT2) * 1000
      message("TT2: " .. TT2 .."; f = " .. f)

        -- вывод результата
        out = out .. string.format("%.3f мс, функции %.3f мс, T1/T2 = %.2f", TT1, TT2, TT1 / TT2)
        message(out)
         return
   end
   run = false

end

Результаты у одного брокера:
   TYPE   DATE   TIME   MESSAGE
1   1   29.10.2025   9:47:15   TT1: 555.00000000029; c = 100000
2   1   29.10.2025   9:47:15   TT2: 7.9999999998108; f = 100000
3   1   29.10.2025   9:47:15   Результат теста: количество вызовов = 100000, время вызова сопрограммы 555.000 мс, функции 8.000 мс, T1/T2 = 69.38

Ну по крайней мере, что то похожее на обсуждение!  :smile:  
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
TGB, В QUIK задача function main() создать поток в котором исполняется скрипт (с корутинами, либо без них) , именно так не иначе, Но Вы то зачем так, как "Профессор" передергиваете?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Совсем упустил. Просто на помню Профессору: "Нечеткое множество — это объект, а нечеткая логика — это система правил для работы с такими объектами." Так я про систему правил, ни ни про множество! И тут Профессор все передернул, а зачем?
Помним "Образ/Подобие", "Объект/Система".
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Профессионалу от дилетанта:

1. Начну с начала (хотя у Вас почему то суть в конце?).
Суть: "Было бы неплохо, если бы можно было бы обсуждать  на форуме конкретные алгоритмы для торговых роботов на луа для QUIK," Читаем название Вкладки "Программирование на языке Lua". Написать три буквы "L, U, A" с точки зрения "профессора по написанию торговых роботов на луа для QUIK" - это высший пилотаж в обсуждении?

2. "Видящий да увидит, слышащий да услышит!". Темы которые я иногда затрагиваю напрямую относятся к торговым алгоритмам, а подходы описанные за чистую Вы не найдете ни в одном учебнике. Судить о них позволяет мое базовое образование (времен когда еще в медицине давали клятву Гипократа, а поколения не делились по признакам знания высказывания "Сообразить на троих"). Идеи выложенные на форуме не каждому дано понять, и здесь нужно просто понимать, что у Все разные способности, кто то хороший доктор, кто то адвокат, а торговать могут все?

3. Не большой секрет. Торговать на бирже в рамках данного форума, подключить э. устройство к серверу QUIK, и в путь (не нужно ни куда ходить?).

4. Про любимую тему профессора, замеры скоростей. В первую очередь нужно научиться отличать "Образ/Подобие". Ни слова про оптимизацию скриптов, а про быстродействие и скорости в ущерб функциональности, удобству, универсальности. И главное здесь, сама система: "Биржа - Сервер - Терминал - Скрипт", поймете это само собой все отпадет.

Ну и конечно в Ваших разработках всяческой удачи. Читаем пункт 1.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
А это самая у Вас крутая разработка:
Цитата
VPM написал:
создать любое число функций main
main() Создано!  :smile:  
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Уважаемый nikolz,  Вы поймите одну простую истину, здесь пользователи собрались, для ТОРГОВЛИ, а не для изучения языков программирования, тем более таких как Си.  :smile:

Что касается меня так, я уже не помню как писать на Бейсик и Фортран, уж не приходится говорить о Си. C Lua разбираюсь по тому что он встроен в терминал, с таким же успехом разбирался бы с любым другим. На нем можно проверять свои торговые идеи, и не только, атематические торговые программы, с гордым названием Робот. Я пишу про это. Для этого не нужен ни Си ни какой другой язык, Lua с избытком. Даже он в некоторых случаях сложен, если учитывать как реализован сам торговый терминал. Язык встроенный необходим нам для автоматизации торговых решений.
Если уж писать то грамотно, приходится придерживаться нескольких основополагающих принципов.

А для того чтоб торговать вообще не нужны ни какие языки, да и образования достаточно царской - приходской школы, арифметики. И причем тут Ваши изыски?  
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
nikolz написал:
Еще надежнее вообще без функций на луа.
Большинство так и пишет.
Цитата
nikolz написал:
17.2  пустая корутина 0.6  пустая функция 0.4  пустой if
Скорость исполнения полезно знать, но не нужно путать задачи?

* If - встроенный оператор сравнения, и так понятно что самая быстрая операция (фильтрация, больше не для чего ни годится);
* функция - разделение кода по функциональности,  (полную задачу делим, хотя бы чтоб можно было читать);
* корутина - это сервис для исполнения  минимального кода, что бы была возможность "за ходить в гости в точку С, а не просто шагать из А до Б".

Вот и смысл: "А И Б сидели на трубе, А - упало, Б - пропало, кто остался на требе?"  :smile:  
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Nikolay,  Вы знаете, тестил  до 100  корутин одновременно (правда не долго),  у меня сложилось хорошее впечатление, если вылетает то нет блокировки всего кода. Показывает не исправность одного датчика, ошибка конкретизируется.

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

Насчет колбеков у меня тоже много вопросов. И основной для КОГО сделано? Мы пришли все таки торговать, а не решать задачи программирования. По мне так интерфейс пользователя, вон как в Метасток или того проще, с возможностью разворачивания для спецов. А в такой реализации, как сейчас, все должны быть спецами, а не торгашами.

Кстати проблема с отслеживанием статусов HackTrade, возникала давно, но при работе с портфелем и редких сделках, все откладывал, а тут прямо реально достала. Заодно делаю рефакторинг  framework у, чтоб получал данные с подпиской на свечи с удобным интерфейсом пользователя. Не очень удобно реализована работа если нужно получать с разных тайм фреймов. Может выложу позже на обсуждение? Пока нравится по крайней мере наиболее удобная у меня версия.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
framework это просто упрощение при создании торговой логике.  Избавляет от взаимодействия с квик, (принцип один раз отладил и забыл, только подключаем).

Что делает framework, решает две основные задачи:
1. Получение данных из квик из разных источников;
2. управление заявкой. Под задачи управления: отправка, снятие, перестановку заявок, обработку их статусов ну и так далее. (Именно эту проблему я и поймал - обработку статусов, что и ломало весь код.)

Вариант от Nikolay, как то я с ним не очень подружился, хотя необходим для поднятия и восстановления истории.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
nikolz,  Так оно так и есть, создаем конфигурацию к робот, строим необходимую торговою логику или используем заготовки торговых стратегий и в бой.

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

Например вот файл конфигурации к стратегии описанной выше:
Код
--[[ КОНФИГУРАЦИЯ ]]--
local Config = {
        --Config.Trading.account  Config.Trading.client_code
    Trading = {
        market = "TQBR",
        ticker = "SBER",
        account = "L01+00000F00",
        client_code = "21045400",
        firmid = "MC0031400000",
        order_type = "LIMIT",
        time_in_force = "GTC",
        volatility_period = 20,
        regime_detection = true,
        
        max_order_retries = 3,      -- максимум 3 попытки перевыставления
        retry_delay = 5,            -- задержка 5 секунд между попытками
        order_timeout = 30          -- таймаут ордера 30 секунд
    },

    Grid = {
        levels = 5,
        base_lot = 1,
        step_type = "ADAPTIVE",
        step_ticks = 5,
        min_ticks = 3,
        max_ticks = 8,
        grid_levels = 5, 
        lots_per_level = 1,
        grid_step = 0.1,
        --account = "L01+00000F00",    -- ДУБЛИРУЕМ ДЛЯ GridManager
        --client = "21045400",         -- ДУБЛИРУЕМ ДЛЯ GridManager
        
        martingale = {
            enabled = true,
            type = "OPTIMAL",
            factor = 1.3,
            max_levels = 3,
        },
        
        take_profit = {
            type = "DYNAMIC", 
            ticks = 8,
            multiplier = 1.6,
        },
        
        hedge_enabled = true,
        auto_rebalance = true,
        rebalance_threshold = 0.7,
    },
    
    Risk = {
        total_capital = 1000000,
        risk_per_trade = 0.02,
        max_instrument_risk = 0.05,
        max_portfolio_risk = 0.15,
        reserve_ratio = 0.1,
        margin_safety = 1.5,
        max_position_value = 0.2,
        max_total_exposure = 0.4,
        stop_loss_individual = 0.05,
        stop_loss_portfolio = 0.08,
        daily_loss_limit = 0.05,
        max_drawdown_limit = 0.15,
        position_sizing = "KELLY",
        kelly_fraction = 0.5,
    },

    GUI = {
        enabled = true,
        update_interval = 2,
        show_detailed_stats = true,
        alert_on_limits = true,
    }
}
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
nikolz,  Да Вы все правильно говорите. Наверняка мой код не оптимален можно большего быстродействия добиться, все это так. Я еще тот писатель.

Речь здесь идет совершенно о другом: про надежность, про универсальность подхода и быстрое простое создание стратегии. Задача частного трейдера мало чем отличается от профессионального трейдинга. Только в профессиональном работают отделами, каждый из которых отвечает за свою область. А частный за все сразу. Вопрос у кого больше шансов наделать ошибок? Использование подходов с фреймворк помогает упростить, частнику ряд задач и заниматься непосредственно трейдингом.

Моя задача сводилась к элементарной задаче в трейдинге, снижению цены позиции в убыточной сделке на одном инструменте, (правильно так, уменьшения диапазона между текущей ценой и ценной набранной позиции). Для этого случая идеально подходит "торговая стратегия сетка + HackTrade - (frameworkупрощение при создании, как исполнитель, гарантировано набирает позицию), нужно дописать несколько модулей  RiskManager, MoneyManager, GridManager. И дело в шляпе.

RiskManager, MoneyManager, GridManager это тоже модули подключаемые. То есть мы имеем в своем распоряжении некий конструктор. Под который создается торговая стратегия. В моем распоряжении сейчас:
- Арбитражные стратегии - несколько инструментов;
- Маркет-мейкинг - сетки заявок в разных вариантах;
- Мульти-инструментальные стратегии - портфельный подход;
- Парный трейдинг - связанные инструменты;
- Хеджирование - противоположные позиции.
Создание стратегии за 3 минуты. И мы уже "на боевом коне" и нас голыми руками не взять. Так ка время остается и на расчеты рисков, целей, и можно занимаемся деятельность трейдера, управлением Капитала.

Вот пример интерфейса конечного пользователя (конечный автомат) и это уже рабочий код (по сути трендовая), ну что еще проще может быть:
Код
dofile("hacktrade.lua")
function Robot()

  feed = MarketData{
    market = "MCODE",
    ticker = "TCKR",
  }
  
  order = SmartOrder{
    market = "MCODE",
    ticker = "TCKR",
    account = "ACNT1234567890",
    client = "775533",
  }

  ind = Indicator{tag="MYIND"}

  while true do
    if feed.last > ind[-2] then
      order:update(feed.last, 1)
    elseif feed.last < ind[-2] then
      order:update(feed.last, -1)
    end
    Trade()
  end
end

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

3. Про "так как coroutine не вычисляются параллельно, а исполняются в бесконечном цикле main", Вы ни как не поймете, что в этом то заключается вся ПРЕЛЕСТЬ. Именно это позволяет строить логику кусочно и выполнять код тогда, когда это нужно. Это и есть асинхронность исполнения кода, что позволяет добиваться уникальности в логике и алгоритмах.

4. Мой восторг по поводу скрипта HackTrade выражается не слом "сказка" а словом "Гениально"!
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Сказка4. «Через тернии к звёздам».
"Тернии" опустим, все таки личное, а многое, с чем столкнёшься используя этот подход, уже ясно из описания самого подхода. А отказаться от него вообще не вариант, сейчас поясню!

Сразу «к звёздам»! Во избежание получения эффекта опасности "лапши из булевых флагов" (где то попалась терминология, хорошо описывает проблематику), когда система управляется разрозненными переменными, были собраны принципиально разные варианты философии с умными stateful-заявками.

HackTrade Pro version 2.0 - Много заявочная версия. Эта переработанная версия сохраняет обратную совместимость с оригинальным HackTrade 1.4, но добавляет:
1. Современную OOP архитектуру с классами Order, OrderManager;
2. Безопасную машину состояний для ордеров;
3. Систему событий для реактивного программирования;
4. Расширенную статистику и аналитику;
5. Улучшенное управление сетками ордеров.
Доводил "сломано много копий", рабочий получилась 2.3 но не обоснована сложа, хотя и рабочая. Данную версию отнесу в "Тернии".

Наиболее интересным получился HackTrade Pro version 3.0. Хорошо сохраняет оригинальную концепцию. Реализованы ключевые принципы, заточенные под задачи алгоритмического трейдинга:
-  Конечное число состояний. Система может находиться в конкретном состоянии (есть активный ордер, нет ордера, ордер на покупку/продажу);
-  Четкие переходы: Метод process() проверяет текущее состояние и решает, нужно ли выставлять, отменять или перевыставлять заявку;
-  Предсказуемость: В каждый момент времени известно, что пытается сделать заявка и каково ее целевое состояние.

Сравнение. Вот как подход соотносится с классической машиной состояний:

| Аспект         | "HackTrade Pro 3.0 (SmartOrder)"                  | "Классическая State Machine"                         |
|  ---           |  ---                                              |  ---                                                 |
| "Суть подхода" | Специализированная машина состояний для трейдинга | Универсальная модель (например, XState)              |
| "Состояния"    | `position`, `planned`, `price` (данные + цель)    | Четкие состояния: `pending`, `executed`, `cancelled` |
| "Переходы"     | Автоматические через `process()`                  | Через явные события (event-driven)                   |
| "Гибкость"     | Высокая для торговых задач                        | Общая, для любых систем                              |
| "Сложность"    | Низкая, минимальный boilerplate                   | Выше, требует настройки                              |

Что сохранено из оригинального HackTrade:
1. Stateful умные заявки - помнят свое состояние (position, planned, `price);
2. Автоматическое управление - сами выставляют/снимают/перевыставляют заявки;
3. Динамическая адаптация - при изменении update() автоматически корректируют активные заявки;
4. Гарантированное исполнение - стремятся достичь целевой позиции несмотря на рыночные изменения;
5. Обратная совместимость - тот же API ( order:update(price, quantity) )
6. Простота использования - создание заявки в 3 строки кода.
Что улучшил:
1.  Добавил обработку ошибок и "edge cases"
2.  Улучшил безопасность с проверками nil значений

Что УЛУЧШЕНО в HackTrade Pro 3.0:

| Аспект                                   | HackTrade 1.4              | HackTrade Pro 3.0                                              |
|--------                                      |---------------                    |-------------------                                                       |
| "Архитектура"                       | Процедурный подход  | Чистая OOP с мета таблицами                         |
| "Обработка ошибок"            | Базовая                        | Расширенная валидация и логирование          |
| "Система событий"              | Отсутствует                  | Встроенная (`on()`, `emit()`)                                |
| "Управление состояниями" | Неявное                        | Явная логика переходов в `process()`               |
| "Безопасность trans_id"       | Риск коллизий              | Уникальная генерация с проверкой                   |
| "Мониторинг"                        | Логирование                 | Полная статистика и статус                               |
| "Расширяемость"                 | Сложная                        | Легкое добавление новой функциональности |

HackTrade Pro 3.0 - Много заявочная версия, поддерживает торговые стратегии:

- Арбитражные стратегии - несколько инструментов;
- Маркет-мейкинг - сетки заявок в разных вариантах;
- Мульти-инструментальные стратегии - портфельный подход;
- Парный трейдинг - связанные инструменты;
- Хеджирование - противоположные позиции.

Надеюсь не сильно утомил своими сказочками, это рассказ про то, как один небольшой но принципиальный недочет, отнимает массу времени и помогает "Кумекать"  :smile:  
Всем  хорошего кода.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Пару слов про подход.
-------------------------------
Технологическая философия оригинального HackTrade с умными stateful-заявками, его инженерия, это не что иное как реализация варианта специализированной машины состояний для трейдинга. Да. "SmartOrder" — это state machine, воплощенная в виде умной заявки, а не в виде абстрактного графа состояний. Это практический подход, который сохраняет все преимущества state machines — предсказуемость, надежность и отсутствие невозможных состояний — в контексте, реальной торговле на бирже.
Эта "stateful-заявка (SmartOrder)", которая сама управляет своим жизненным циклом, что является классическим применением паттерна state machine. Ну согласитесь ведь гениально! Конечным автоматом в этой философии выступает, алгоритм торговой стратегии (мы создаем функцию "Robot"). С простым и очень понятным пользовательским интерфейсом.

По своей сложности. Очень сложно!
В реализации подхода задействовано все чем силен скриптовый язык Lua:
* таблицы реализованные как объекты подход (ОПП) с мета методами;
*  основной цикл программы разбит сопрограммами, что превращает выполнение в асинхронное;
*  модульность добавляет универсальность.
Тяжело не только разобраться, но еще сложнее отладить.

SmartOrder спроектирован, так что обслуживает одну умную заявку, но не что не мешает создавать пул из умных заявок. Для большинства роботов нe хватит одной умной заявки, но мы можем создавать их больше, например для сетки маркет - мейкера, когда в рынке стоят сразу несколько заявок.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Сказка3. "ни словами сказать ни пером описать".

Напомню свое решение торговой системы: HackTrade + RiskManager + MoneyManager + GridManager (торговая стратегия сетка) + GUI.

HackTrade = Умные заявки (SmartOrder). "Представлена реализация stateful-заявок, которые помнят своё внутреннее состояние и могут динамически принимать изменения параметров. Этот подход сильно отличается от традиционных лимитных заявок. Заявка в фреймворке HackTrade представляет собой динамическую лимитную заявку с изменяемой ценой. При этом также может меняться количество и даже направление. Главное, то нужно запомнить, "умная заявка" будет пытаться набирать указанное количество лотов по заданной цене. Даже если вы снимите заявку торговой систем, SmartOrder породит новую и продолжить добирать заданное ранее количество (представьте, что SmartOrder - это заявка, которая гарантированно набирает зaданный объём)".

`SmartOrder` структурно, представляет собой объект (ОПП), который управляет динамическими лимитными заявками. Он следит за состоянием заявки, может корректировать цену и объём заявки и принимать решения на основе того, как рынок ведёт себя (например, снимать заявки, когда цена или объём изменяются)

Работа с ордерами в сводится к 2 моментам:
  * Если заявка активна, но не соответствует текущим данным (например, цена изменилась), происходит её отмена и пересоздание с новыми параметрами.
  * Если заявка ещё не была отправлена (поле `self.order` пусто), то создаётся новая лимитная заявка.

Пример работы алгоритма:

1. Инициализация заявки. При запуске робота создаётся объект `SmartOrder`, который получает уникальный `trans_id`. В дальнейшем этот объект будет управлять состоянием заявки.

2. Обновление заявки. Когда происходит обновление с новыми параметрами (например, новая цена или объём), метод `update` обновляет эти данные, и заявка готова к выполнению или корректировке.

3. Обработка заявки.  В методе `process()` происходит анализ текущей заявки. Если она не соответствует нужным условиям (например, её нужно отменить), то вызывается соответствующая операция для отмены старой заявки и создания новой с актуальными параметрами.

4. Отправка заявки на рынок. Когда необходимо выставить заявку, это делается через метод `sendTransaction`, который отправляет команду на сервер для создания или отмены заявки.  

Моя идея заключалась: SmartOrder = LevelGrid, то есть присваиваются все свойства SmartOrder, следовательно LevelGrid становится объектом (ОПП) и управляется алгоритмом SmartOrder.

Все не объяснимое начинается здесь.
Цитата
Nikolay написал:
При этом trans_id может появится не с первого колбека, а, скажем, со второго.
От себя добавлю или неизвестно когда?   :cry:  В своих реализациях, насмотрелся такого "ни словами сказать ни пером описать".
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
nikolz,   Спасибо за уточнение. Да, Вы абсолютно правильно отметили. В контексте торговых систем, такие идентификаторы как trans_id и order_num часто используются для уникальной идентификации заявок и операций, но их назначение и контекст отличаются.

trans_id: Это идентификатор транзакции, который обычно используется для отслеживания транзакций внутри самой торговой системы или между различными её частями. Этот ID генерируется на стороне клиента (например, на уровне торгового робота) и может быть использован для уникальной идентификации всех операций, связанных с данной заявкой. Это полезно для внутреннего учёта робота или системы и может быть использован для отмены или модификации заявок.

order_num: Это идентификатор, который обычно генерируется на стороне биржи или брокера и используется для уникальной идентификации заявки в их системе. Когда заявка отправляется на биржу, она получает свой номер — order_num. Этот номер важен для взаимодействия с внешней торговой системой (биржей или брокером), например, для отмены заявки или запроса статуса заявки.

Мое понимание.
Пример: Когда робот создаёт заявку, он может использовать trans_id, чтобы отслеживать все операции с этой заявкой. Если заявка требует изменения или отмены, этот идентификатор будет использоваться для корректного обращения к ней.
Пример: После того как заявка была отправлена на биржу, она получает свой order_num, который будет использоваться для её отслеживания на бирже, а также для отмены или изменения заявки через API биржи.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Nikolay,  Отличное замечание! Спасибо за уточнение! Вы абсолютно правы - в реальной торговле важно правильно работать с идентификаторами. Это очень важное замечание, которое имеет большое значение для правильного построения системы и логики работы с ордерами в рамках торговых систем!
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Сказка2. Решение моментальное - использовать оба идентификатора. Почему важно использовать оба идентификатора:

1. "'trans_id'" — уникальный идентификатор транзакции, который используется для идентификации заявки на более высоком уровне (в рамках системы торговли или брокера). Этот идентификатор часто используется для отслеживания всей жизненной циклы заявки, например, когда она была создана, изменена или отменена.

2. "'order_num'" — уникальный идентификатор самой заявки в рамках торговой системы. Он уникален для каждого ордера и нужен для точной идентификации и управления заявками (например, отмена или модификация заявки). Также 'order_num' используется при возврате данных о состоянии ордера после его выполнения.

Почему нельзя использовать только один из идентификаторов (например, 'order_num'):
Статус и состояние. Состояние заявки (например, активна/отменена) нужно отслеживать в контексте как 'trans_id', так и 'order_num', чтобы правильно обработать ситуацию, если заявка была отменена, частично исполнена или изменена?

Тогда правильная структура и использование двух идентификаторов:
1. Для каждой заявки должен быть свой уникальный 'trans_id'" (для управления жизненным циклом).
2. Для каждой заявки также должен быть свой уникальный 'order_num'", который будет использоваться для отправки ордеров на рынок и их модификации.
3. Важно отслеживать состояние заявки с использованием обоих идентификаторов", чтобы правильно учитывать возможные изменения, отмены или частичные исполнения.

Обновленный подход к обработке заявок: Если хотим точно отслеживать и обрабатывать заявки в пуле, то следует использовать "и 'trans_id', и 'order_num'" для каждой заявки.

Итог:
а) 'trans_id'" и "'order_num'" — это два взаимосвязанных идентификатора для каждой заявки. Каждый из них выполняет свою роль:
   * 'trans_id' связан с транзакцией (управление на уровне системы),
   * 'order_num' — с ордером на рынке (конкретная заявка).
б) Оба идентификатора должны быть сохранены и использованы" для правильной обработки заявок и их состояния, чтобы избежать путаницы и обеспечить точное управление заявками и транзакциями в пуле.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Сказки на ночь, или как вылечить "чихание" колбеков в квик.

Начну с начала.

Сказка1. Допустил на инвестиционном счете (прошу не путать со спекулятивным) приличные просадки по отдельным бумагам, не то чтобы катастрофа, но "глаз мозолит".  Решение было моментальное - усреднить. Счет маржинальный со средствами нет проблем. Огляделся вокруг, оказывается нет у меня подходящего инструмента для решения задачи в атематическом (алгоритмическом) режиме, все больше про бизнес и портфели. Опять решение моментальное - есть торговая стратегия сетка + HackTrade Nano-framework (как исполнитель, гарантировано набирает позицию), нужно дописать несколько модулей, вот основные из которых RiskManager, MoneyManager, GridManager. Задача решаема и быстрая. Слепил из того что было модульный асинхронный вариант.

И вот вам нате! Полезли ошибки в управлении ордерами (не квик то, безусловно виноват ведь "чихает"  :smile: ) Но квик такой какой есть и с этим приходиться жить. Руками торговать не вариант, решение моментальное -  "лечиться". Пробежался на просторах, проблема как и предполагал оказалось в получении колбеками информации с сервера.

В моем скрипте три торговых колбека связаны через свой уникальный идентификатор trans_id. Все три колбека — 'OnTransReply', 'OnOrder' и 'OnTrade' — можно связать через 'trans_id', чтобы отслеживать состояние каждой заявки в процессе её жизненного цикла. Не туто было!

Оказывается состояние ордера в колбеке 'OnOrder' можно отследить единственным способом: "'order_num'" — уникальный идентификатор самой заявки в рамках торговой системы.
* Он уникален для каждого ордера и нужен для точной идентификации и управления заявками (например, отмена или модификация заявки). Также 'order_num' используется при возврате данных о состоянии ордера после его выполнения.
*  "'trans_id'" — уникальный идентификатор транзакции, который используется для идентификации заявки на более высоком уровне (в рамках системы торговли или брокера). Этот идентификатор часто используется для отслеживания всей жизненной циклы заявки, например, когда она была создана, изменена или отменена.

И тут возникает основной вопрос повествования, нет ни кто придумал это, а для Кого? Какими профессиональными знаниями нужно обладать, чтоб со всем этим справляться и не сдаться?  Вопрос прежний для Кого?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Новая роль учредителя. В этой модели мы — не просто CEO, а учредитель и основной бенефициар (отдельной компании). Наша задача — управлять компанией «Я Holdings» так, чтобы:

1.  Ее операционная деятельность (доходы от инвестиций) полностью покрывала ваши финансовые изъятия (вашу "зарплату").
2.  Ее инвестиционная деятельность (реинвестирование прибыли) обеспечивала постоянный рост капитала для защиты от инфляции и увеличения будущих доходов.

Когда эти условия выполняются, наш инвестиционный бизнес становится по-настоящему пассивным источником дохода и финансовой независимости.

Переход от бухгалтерской констатации фактов и финансового планирования к настоящему финансовому анализу. Да, мы должны это оценить. «И тогда наверняка вдруг запляшут облака» — метафора для этого эффекта, который дают эти рычаги: они могут вознести к облакам, но могут и породить грозу.

Оценим операционный и финансовый рычаг для нашей инвестиционной компании «Я Holdings».

1. Операционный рычаг (Леверидж) в инвестиционной компании. Что это такое? В классическом бизнесе — это отношение постоянных затрат к переменным. В нашем случае — это структура доходов компании.
*   Компания с ВЫСОКИМ операционным рычагом: Доход формируется в основном за счет роста капитала (продажа подорожавших активов). Это акции роста, венчурные проекты. Доля дивидендов мала.
*   Компания с НИЗКИМ операционным рычагом: Доход формируется в основном за счет текущих денежных потоков (дивиденды, купоны). Это дивидендные аристократы, облигации.

Как оценить? Коэффициент операционного рычага = (Доход от прироста капитала) / (Денежный доход (дивиденды + купоны)).
*   > 1 (Высокий рычаг):** Ваша прибыль сильно зависит от рыночной конъюнктуры. На бычьем рынке «облака запляшут» — доходность взлетит. На медвежьем — у вас не будет стабильного денежного потока для изъятий, придется продавать активы в убыток.
*   = 1 (Сбалансированный):** Золотая середина. Есть и рост, и стабильный cash flow.
*   < 1 (Низкий рычаг):** Ваша компания устойчива. Она генерирует стабильный денежный поток, почти не зависящий от курсовых колебаний. Но и взлететь к «облакам» ей сложнее.

Пример:
а)   Портфель А (Высокий рычаг): За год получили 50 тыс. руб. дивидендов и 500 тыс. руб. прибыли от продажи акций.
      Рычаг = 500 / 50 = 10.  Высокий. Доходность «пляшет» вместе с рынком.
б)   Портфель Б (Низкий рычаг): За год получили 400 тыс. руб. дивидендов и 100 тыс. руб. прибыли от продаж.
      Рычаг = 100 / 400 = 0.25. Низкий. Компания стабильна, как скала.

2. Финансовый рычаг (Леверидж) в инвестиционной компании. Что это такое? Это использование заемных средств для увеличения размера инвестируемого капитала. То самое «плечо» (leverage). Как оценить? Есть несколько ключевых метрик:
а) Коэффициент финансового левериджа = Обязательства / Капитал.
*   0.5 (1:2): На 1 рубль заемных средств приходится 2 рубля собственных. Консервативно.
*   1.0 (1:1): Соотношение 50/50. Агрессивно.
*   > 1.0: Заемных средств больше, чем собственных. Крайне рискованно.

б) Ставка покрытия долга = (Операционный Денежный Поток) / (Проценты по долгу).
*   > 3: Отлично. Доходы более чем в 3 раза покрывают процентные платежи.
*   1 - 2: Опасно. Почти все денежные потоки съедают проценты.
*   < 1: Критично. Вы не можете обслуживать долг из текущих доходов.

Совместный эффект двух рычагов. Вот где начинается настоящая магия и настоящий риск. Эффекты рычагов умножаются, а не складываются!

Сценарий 1: «Облака запляшут» (Золотой сценарий).
*   Высокий операционный рычаг - (портфель из растущих акций) + Умеренный финансовый рычаг (дешевое плечо 1:0.5).
*   Результат: На бычьем рынке мы получаем доходность не только на свои деньги, но и на заемные. Наш капитал растет опережающими темпами.

Сценарий 2: «Гроза и шторм» (Катастрофический сценарий).
*   Высокий операционный рычаг** (волатильные активы) + Высокий финансовый рычаг (плечо 1:1 или выше).
*   Результат: На медвежьем рынке падение стоимости залога приводит к маржин-коллу. Брокер принудительно продает наши активы по низким ценам, фиксируя убытки и уничтожая наш капитал. Это тот случай, когда «облака» не пляшут, а обрушиваются ливнем.

Сценарий 3: «Уверенный рост» (Стратегия богатого папы).
*   Низкий операционный рычаг - (портфель генерирует стабильный cash flow) + Умеренный финансовый рычаг (дешевый долг, например, ипотека на доходную недвижимость).
*   Результат: Наш арендный денежный поток стабильно покрывает платежи по кредиту и наши изъятия. Компания растет надежно и предсказуемо.

Резюме для CEO «Я Holdings».
1.  Операционный рычаг — это наш выбор стратегии (рост vs. доход). Определяет волатильность нашей прибыли.
2.  Финансовый рычаг — это наш источник финансирования (свои vs. заемные). Определяет уровень риска ликвидации.
3.  Вместе они создают коктейль с непредсказуемым эффектом. Высокие значения обоих рычагов — удел профессионалов, готовых к полной потере капитала.

Теперь наша задача как управляющего. Найти такое сочетание рычагов, который соответствует нашему темпераменту, опыту и горизонту инвестирования. Для большинства «облака запляшут» при умеренном операционном и минимальном финансовом рычаге. :smile:  Помним: рычаг режет в обе стороны.
------------------------

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

Формализуем эту задачу. Эту проблему идеально моделировать как задачу оптимального управления с граничными условиями, где мы управляем двумя видами рычагов для максимизации функции роста капитала при ограничении на максимальный убыток. Но это уже другая тема.  
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
                                                                                                                                                  "... С голубого ручейка начинается река ..."

Внесу уточнение в модель, когда мы рассматриваем инвестиционную компанию как самостоятельный бизнес, фокус несколько смещается, и на мой взгляд упрощается, ведь  управление отдельной компанией проще управления холдингом, сохраним рабочее название прежним «Я Holdings». Уточним модель для этого случая.

В этой модели компания «Я Holdings» — это самостоятельный бизнес, который живет по своим внутренним законам. Её цель — самоокупаемость и рост за счет реинвестирования прибыли.

Ключевые допущения:
*   Источник средств: Первоначальные взносы учредителей (наши личные накопления).
*   Доходы: Только доходы от инвестиционной деятельности (дивиденды, купоны, реализованная прибыль от продажи активов).
*   Расходы: Все изъятия средств учредителями на личные цели, а также комиссии и налоги.
*   Реинвестирование: Вся нераспределенная прибыль остается в компании и реинвестируется.

Три главных отчета остаются прежними, внесу лишь уточнение, в Отчет о движении денежных средств (ДДС) — «Хватает ли компании денег?»*. Это по-прежнему самый важный отчет, но его структура меняется.

*   Операционная деятельность (ОСНОВНАЯ): Доходы от инвестиций.
   *   Приток: Дивиденды, купоны, проценты.
   *   Отток: Комиссии брокеров, оплата услуг управляющего.
*   Инвестиционная деятельность (ЦЕЛЕВАЯ): Покупка и продажа активов.
   *   Отток: Покупка новых акций, облигаций.
   *   Приток: Продажа активов (возврат капитала).
*   Финансовая деятельность (СВЯЗЬ С ВЛАДЕЛЬЦЕМ): Взаимодействие с учредителем.
   *   Приток: Дополнительные взносы учредителя.
   *   *Отток: Изъятия учредителя на личные расходы.

Главная формула успеха для самоокупаемой компании: Операционный Денежный Поток >= Изъятия (Финансовая деятельность)
*   Цель достигнута: Если дивидендов и купонов хватает на все ваши изъятия, значит, компания вышла на самоокупаемость. Вы живете на доход от ее деятельности, не трогая основной капитал.
*   Цель не достигнута: Если изъятия больше операционного потока, вам приходится продавать активы (Инвестиционная деятельность) или докладывать свои деньги (Финансовая деятельность), что тормозит рост.

2. Отчет о прибылях и убытках (ОПУ) — «Прибыльна ли компания?»

*   Выручка: Совокупный инвестиционный доход (дивиденды + купоны + реализованная прибыль от продаж).
*   Расходы: Комиссии, налоги.
*   Чистая прибыль / убыток: Выручка - Расходы.
*   Важный нюанс: Нереализованная прибыль/убыток (изменение стоимости портфеля) здесь не отражается. Этот отчет показывает реальный денежный результат.

3. Баланс — «Сколько стоит компания?»

*   АКТИВЫ: Только инвестиционные активы. Деньги на брокерском счете, акции, облигации, ETF.
   (Личные активы типа машины и квартиры теперь не учитываются — они принадлежат нам лично, а не компании ).
*   ОБЯЗАТЕЛЬСТВА: Кредитное плечо, маржинальные займы.
*   КАПИТАЛ: Активы - Обязательства. Это чистая стоимость вашего инвестиционного бизнеса. Рост капитала — главная KPI.
---
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Пару слов про показатели метода.

Забегая вперед отмечу, что прекрасно вписываются в данный подход и метрики трейдинга:
*   Профит фактор,
*   Процент выигрышных сделок,
*   Мат. ожидания системы, без расчета которого не должна существовать ни одна система, в том числе и данная.
Управление капиталом вообще отдельная тема, но я сейчас про управление системой как бизнес. Вот система метрик ни чего нового, то как понимаю подход, структурированная по трем основным отчетам и ключевым бизнес-процессам.

1. Метрики Операционной деятельности (Income Statement & Cash Flow).
Цель: Оценить эффективность генерации свободных денежных средств — «топлива» для инвестиций.

*   Коэффициент сбережений (Savings Rate):
   *   Формула: (Доходы - Расходы) / Доходы * 100%
   *   Смысл: Это*рентабельность по чистой прибыли (Net Profit Margin) нашего личного «бизнеса». Показывает, какая доля дохода остается после всех жизненных «операционных расходов». Цель — постоянное увеличение.
*   Свободный денежный поток (Free Cash Flow - FCF):
   *   Формула: Доходы - Все расходы (включая налоги и обязательные платежи)
   *   Смысл: Абсолютная сумма в рублях/долларах, которую вы можете направить в инвестиционную деятельность (CFI) без привлечения заемных средств. Это главный источник роста.

2. Метрики Финансовой деятельности (Balance Sheet & Leverage).
Цель: Оценить финансовое здоровье, структуру капитала и риски, связанные с долгом.

*   Коэффициент долговой нагрузки (Debt-to-Income Ratio - DTI):
   *   Формула: Сумма ежемесячных платежей по долгам / Ежемесячный доход * 100%
   *   Смысл: Показывает, какая часть вашего операционного cash flow съедается обслуживанием долга. >40-50% — сигнал опасности.
*   Коэффициент финансового рычага (Leverage Ratio):
   *   Формула: Обязательства / Активы или Обязательства / Собственный капитал (Equity)
   *   Смысл: Показывает, насколько вы зависите от заемных средств. Для частного инвестора цель — низкое значение (например, <0.3 или 30%).
*   Стоимость заемного капитала (Cost of Debt):
   *   Формула: Средневзвешенная процентная ставка по всем кредитам
   *   Смысл: Критически важная метрика. Доходность от инвестиций (CFI) должна быть заведомо выше этой цифры.

3. Метрики Инвестиционной деятельности (Performance & Efficiency)
Цель: Оценить эффективность управления портфелем-проектом.

*   Общая доходность портфеля (Total Portfolio Return):
   *   Формула: (Текущая стоимость портфеля - Внесенные средства) / Внесенные средства * 100%`
   *   Смысл: ROI (Return on Investment) для всего вашего «бизнеса». Показывает общую эффективность.
*   Доходность с учетом дивидендов (Total Return):
   *   Смысл: Важно учитывать не только рост цены, но и реинвестируемый cash flow (дивиденды, купоны). Это более точная метрика.
*   Скорректированная на риск доходность (Risk-Adjusted Return):
   *   Метрика: Коэффициент Шарпа.
   *   Смысл: Показывает, сколько дохода вы получаете за единицу риска (волатильности). Доходность 20% при волатильности 5% гораздо лучше, чем те же 20% при волатильности 25%.
*   Сравнение с бенчмарком (Benchmark Tracking):
   *   Метрика: Отставание/опережение индекса (например, IMOEX или MSCI World).
   *   Смысл: Ответ на вопрос: «А не мог бы я просто купить индекс и спать спокойно?». Если вы отстаете от бенчмарка, ваш «активный» управленческий труд не приносит добавленной стоимости.

4. Метрики Баланса (Balance Sheet Health)
Цель: Оценить структуру и качество активов.

*   Аварийный фонд (Emergency Fund Ratio):
   *   Формула: Сумма на "черный день" / Среднемесячные расходы
   *   Смысл: Показывает, на сколько месяцев вы можете прожить без дохода. Цель — 3-6 месяцев. Это коэффициент ликвидности.
*   Аллокация активов (Asset Allocation):
   *   Метрика: % акций, % облигаций, % кэша, % альтернативных активов
   *   Смысл: Главный драйвер риска и доходности. Отслеживание отклонений от целевой аллокации — основа управления портфелем.
*   Диверсификация (Diversification Metrics):
   *   Метрики:
       *   Количество эмитентов/стран/секторов.
       *   Максимальная доля одного актива в портфеле.* (Например, правило: не более 5% на одну акцию).
   *   Смысл: Показывает уровень несистематического риска. Снижает риск банкротства одного «проекта» для всей «компании».

5. Сводная таблица KPI для CEO «Я Holdings»**

| Сфера               | Ключевая метрика                                      | Целевое значение                                  
| -----------------      | -----------------------------------------                     | -------------------------------------------------        
| Операции          | Коэффициент сбережений (>20%)             | Постоянный рост                                  
|                            | Свободный денежный поток (FCF)             | Положительный и растущий                          
| Финансы            | Коэффициент долговой нагрузки (DTI) (<30%)| Менее 30%                                        
|                            | Стоимость заемного капитала                   | Минимизировать; < ожидаемой доходности портфеля
| Инвестиции       | Общая доходность (Total Return)               | Опережать инфляцию + целевой бенчмарк            
|                            | Коэффициент Шарпа                                  | >1 (чем выше, тем лучше)                          
| Баланс/Риски    | Аварийный фонд                                         | 3-6 месяцев расходов                              
|                            | Отклонение от целевой аллокации           | Не более ±5% по каждому классу активов            
|                            | Макс. доля одного актива                           | Не более 5%                                      

Управляя этими метриками, мы превращаемся из пассивного владельца активов в активного CEO, который на основе данных принимает решения:
   * о распределении капитала,
   * управлении рисками
   * и стратегическом развитии своего главного бизнеса «Я Holdings» — собственного финансового будущего.
-----------------
А не кто и не обещал, что будет легко. :smile:  
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Портфель - как проект в бизнесе. Это завершающая и самая важная мысль.

Каждый актив в нашем портфеле — это не просто "бумажка", а инвестиционный проект со своими параметрами:

*   Бизнес-план. Наша инвестиционная идея. Почему эта акция/облигация должна принести доход?
*   Цель (KPI). Ожидаемая доходность, срок горизонта инвестирования.
*   Бюджет (CAPEX). Сколько мы готовы вложить.
*   Управление рисками. Каковы риски проекта (отраслевые, страновые, валютные)? Какой максимальный убыток мы допускаем (стоп-лосс)?
*   Отчетность. Мы регулярно (но не ежедневно!) смотрим на результаты проекта. И отвечаем себе на вопросы: изменилась ли первоначальная идея? Выполняются ли KPI?

Управление портфелем — это управление «Я Holdings» состоящей из таких проектов.
Вы как CEO компании «Я Holdings»:
1.  Распределяете капитал между проектами (активами).
2.  Закрываете убыточные проекты (продаете активы, если идея не сработала).
3.  Увеличиваете финансирование успешных проектов (докупаете качественные активы).
4.  Следите, чтобы один провальный проект не потопил всю компанию (диверсификация).

Итог. Новая парадигма. Перестаем думать, "Куда бы вложить 1000 рублей?".  Начинаем думать как генеральный директор компании «Я Holdings» - владелец пусть и миноритарий:

1.  Как мне увеличить денежный поток от моей операционной деятельности? (Больше зарабатывать, разумно тратить).
2.  Нужно ли мне привлекать финансовый рычаг для моих инвестиционных проектов, и если да, то на каких условиях? (Осторожно с долгами, это одельная тема управление капиталом).
3.  Какой инвестиционный проект (актив) соответствует моей стратегии и имеет наилучшее соотношение риска и доходности?
4.  Как выглядит отчетность моего "бизнеса" в целом? (Баланс, отчет о прибылях и убытках, движение денежных средств).

Такой подход превращает инвестиции из лотереи в осознанный, управляемый бизнес-процесс. Как Вам такой путь к настоящей финансовой свободе?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Развернем идею и посмотрим на портфельное управление через призму бизнес-управления. (Или "Три богатыря" в управлении бизнесом, а что у них в руках, возможно то самый рычаг?)

Бизнес-подход к личным финансам. Вы — генеральный директор самого себя, или компании под рабочим названием "Я Холдинг" ("IHoldings"). А что имеем полное право, приобретая акции разных компаний, становимся собственниками этих компаний. С точки зрения бизнеса получаем Актив, а диверсификация дает нам право назваться холдингом, что собственно и отрежет смысл владения разными активами. Следовательно и наш личный капитал должен управляться с позиции управляющего холдингом.

Если отразить деятельность "IHoldings" как: Инвестиционная деятельность = Операционная деятельность + Финансовая деятельность. То ее можем описывать так же, как это делает бизнес.

Три основных управленческих отчета при управлении бизнесом (Три богатыря).

а) Отчет о прибылях и убытках (Income Statement) - Отвечает на вопрос: "Как я генерирую денежный поток?"
*   Выручка (Revenue): Дивиденды, купоны, проценты по вкладам, другие средства на инвестирование.
*   Расходы (Expenses): Текущие жизненные траты (если тратим на разные нужды), налоги, комиссии брокеров, затраты на инфраструктуру ...
*   Чистая прибыль (Net Income): = Выручка - Расходы.
*   Смысл: Этот отчет отвечает на вопрос "Насколько эффективно я превращаю свои труд и капитал в свободные деньги?". Положительный и растущий Cash Flow — это топливо для нашей инвестиционной деятельности.

б) Баланс (Balance Sheet) - Отвечает на вопрос: "Чем я владею и кому должен?"
*   Активы (Assets):
   *   Оборотные: Деньги на счетах, вклады.
   *   Внеоборотные: Акции, облигации, ETF, недвижимость, золото.
*   Обязательства (Liabilities):
   *   Краткосрочные: Кредитки, потребительские кредиты.
   *   Долгосрочные: Ипотека, автокредит, маржинальное плечо.
*   Капитал (Equity): = Активы - Обязательства.
*   Смысл: Это моментальный снимок нашего финансового здоровья. Наша цель — не просто рост активов, а рост капитала (Equity). Сильный баланс — это низкая доля обязательств и качественные, диверсифицированные активы.

в) Отчет о движении денежных средств (Cash Flow Statement) - Отвечает на вопрос: "Откуда приходят и куда уходят деньги?"
Это самый важный на мой взгляд в нашей компании отчет! Он делится на три части, которые идеально ложатся на нашу формулу:
1.  Денежный поток от операционной деятельности (CFO): Ваш заработок, минус все жизненные траты. Это фундамент.
2.  Денежный поток от инвестиционной деятельности (CFI): Покупка и продажа активов. Покупка — отток денег (-), продажа — приток (+).
3.  Денежный поток от финансовой деятельности (CFF): Взятие и погашение кредитов, использование плеча. Взятие кредита — приток (+), погашение — отток (-).

И вот наша ключевая формула в действии: CFI = CFO + CFF.
Простыми словами:
  *   Если у вас сильная операционная деятельность (CFO > 0), вы можете инвестировать (CFI < 0 на покупки) без долгов.
  *   Если операционной деятельности не хватает, вы привлекаете финансовую деятельность (кредиты, CFF > 0), чтобы усилить инвестиционную. Хотя это — повышение риска, но и повышение ROI на собственные средства!

Таким образом, управление портфелем есть не что иное как Управление Двумя Рычагами: Операционным и Финансовым.

Рычаг №1: Операционная деятельность (Зарабатывание)
*   Задача: Максимизировать разницу между доходами и расходами.
*   Управление: Повышение квалификации, разумное сокращение неэффективных расходов ("оптимизация издержек").
*   Результат: Увеличение CFO — источника сил для инвестиций без долгов.

Рычаг №2: Финансовая деятельность (Заемные средства)
*   Задача: Привлекать дешевый и долгосрочный капитал для усиления инвестиционной деятельности и .
*   Управление:
   *   Плохо: Дорогие кредитки для спекуляций, короткие плечи на волатильных активах.
   *   Хорошо: Низкопроцентный займ на доходную часть активов, долгосрочное маржинальное плечо для покупки диверсифицированных активов (нужно крайне осторожно!).
*   Ключевой вопрос: Будет ли доходность от актива (CFI) заведомо выше стоимости привлеченных средств (CFF)?

То для успеха нужно управлять обеими составляющими эффективно.  Возникает вопрос так для кого  "доход пассивный"?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Александр М, Так, принимайте участие в обсуждениях, ведь не сторонний человек в трейдинге, всегда интересно мнение со стороны, ведь нельзя оставаться всегда правым. Кстати Ваш журнал хочу опробовать в этом инвест. проекте.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Продолжая тему модернизации инвестиционного портфеля (Рефакторинг кода). Огляделся вокруг, что происходит, каков  рыночный фон?

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

2. Пассивный доход - от куда сегодня только не звучит. Идея простая, Свободные (и не очень) средства направлять на инвестиции или спекуляции. Есть 1000 руб. купил на них Акцию и жди дивиденд, и вот вам доход, Ура. Но все ли так безмятежно.

Что то "пахнет" противоречиями современного инвестирования. Давайте разберем ключевое противоречие по частям.

1. Иллюзия безмятежности, что скрывается за мантрой "пассивного дохода". Главный ключ к пониманию можно обозначить так: «Свои дорогие - после налогов. Заемные - бизнес» — это и есть главный ключ к пониманию.

1.1. «Свои средства — всегда дорогие, после налогов».
Наши 1000 рублей — это не просто 1000 рублей. Это "уже очищенные от налогов" деньги.
     * Если вы работаете по найму, то это ваш зарплатный доход, с которого уже удержан НДФЛ.
     * Если вы предприниматель — вы заплатили налоги с прибыли.

Эти деньги можно потратить на образование, отдых, текущие нужды или на развитие другого бизнеса. Используя их для инвестиций, мы отказываетесь от этих альтернатив. Это и есть их "цена" - Альтернативная стоимость.
Если наши инвестиции (дивиденды + рост стоимости) не покрывают официальную инфляцию (а часто и реальную, которая выше), мы в убытке. Наш "пассивный доход" на самом деле — пассивное проедание капитала - Инфляция как скрытый налог.

Пример: Депозит под 10% при инфляции в 8% и налоге на доход свыше ключевой ставки дает нам мизерную реальную доходность. А дивиденд по акции в 5% при падении цены самой акции на 10% — это убыток.
Вывод: Свои средства лишь *кажутся* бесплатными. Их реальная стоимость определяется упущенными возможностями и инфляцией.

1.2. «Заемные — так поступает бизнес».
Вот здесь начинается настоящая игра с огнем. Использование заемных средств (кредитов, маржинального плеча) кардинально меняет природу операции.

По своим деньгам мы можем переждать просадку. Акция упала на 30%? Мы можем держать ее годами, ожидая восстановления.
С заемными средствами так не получится. При падении стоимости залога брокер вынужден будет продать наши активы по самой низкой цене (маржин - колл), чтобы вернуть себе деньги. Мы превращам временную бумажную просадку в невосполнимый реальный убыток - мы фиксируете убыток! :cry:

Процент по кредиту/марже — это наша постоянная статья расходов. Наши инвестиции должны не просто приносить доход, а приносить доход, заведомо превышающий стоимость этого плеча. Это создает гигантское давление и вынуждает идти на большие риски. Стоимость плеча, это постоянные расходы сказал бы управляющий бизнесмен! Торговля на заемные средства  к тому же — это колоссальный стресс, который приводит к эмоциональным, нерациональным решениям - психологическое давление.
Вывод: Использование заемных средств — это не "инвестирование", это профессиональная спекулятивная деятельность, требующая глубоких знаний, железной дисциплины и готовности к полной потере капитала. :what:

Так что же на самом деле представляет собой эта "1000 рублей в акцию"? Это безмятежный пассивный доход или ЭТО:
1.  Микро-бизнес? Вы становитесь совладельцем бизнеса (акция) или его кредитором (облигация). Бизнес может процветать, а может и обанкротиться.
2.  Управление рисками? Вам нужно диверсифицировать портфель, чтобы крах одной компании не уничтожил все ваши вложения. Те самые 1000 рублей — это не одна акция, а, возможно, доля в ETF на весь рынок.
3.  Постоянная работа и обучение? "Пассивность" — это миф. Даже индексное инвестирование требует регулярной ребалансировки, мониторинга макроэкономической ситуации и железной выдержки, чтобы не продавать активы на панике.
4.  Осознание горизонта инвестирования? Эти 1000 рублей вам не понадобятся в течение 10-15 лет? Отлично, вы можете вложить их в акции. Понадобятся через год? Это должны быть максимально надежные и ликвидные инструменты, с почти нулевой доходностью.

Заключение. Массовый нарратив о "пассивном доходе" часто упрощает реальность до опасной степени. Настоящий пассивный доход — это не результат единоразового действия "купил акцию" и жди дивиденд.

Это результат:
- Постоянного дисциплинированного формирования капитала (сначала накопить, потом инвестировать).
- Грамотной стратегии, основанной на целях и приемлемом для вас риске.
- Понимания всех издержек — как явных (налоги, комиссии), так и неявных (инфляция, альтернативная стоимость).
- Отказа от иллюзий быстрого обогащения, особенно с использованием заемных средств.

Наши 1000 рублей — это не билет в безмятежную жизнь, а "семена будущего капитала". Но чтобы это семя проросло, за ним нужен уход, терпение и понимание, в какой почве оно растет и какие бури могут быть над горизонтом. Это именно тот уровень осознанности, который отделяет "играющего в инвестиции" от профессионального управляющего капиталом.  :smile:

Вывод, по своей экономической природе "пассивны доход" с родни бизнес - управлению компанией. Но тогда и нужно сформировать такой подход, себя превратить, из безмятежного наблюдателя, в генерального директора, владельца бизнеса!  А это уже новая парадигма, дело тут в разных подходах в отношении, если хотите психологии!
Или вариант совсем ни наш, передать управление. :what:
Два варианта использования графического пакета IUP (Lua 5.4) в QUIKе
 
Конкретные смыслы и практические преимущества, или как сопрограммы меняют парадигму!

Смысл 1: Простота - читаемость и ясность кода.
--------------------------------------------------------

* Теория: Мы пишем последовательный код.
* Смысл: Мы можем описать сложную асинхронную логику так, как мы о ней думаем — шаг за шагом, без нагромождения хаоса колбэков.
"Ад колбэков" — код растет вглубь, асинхронная логика размазана по функциям. После (красота сопрограмм)!
Код
function сложнаяЗадача()
    local data = загрузитьДанные("url") -- Здесь может быть yield
    local result = обработатьДанные(data) -- И здесь
    local success = сохранитьВБД(result) -- И здесь
    если success then
        обновитьИнтерфейс()
    end
end
-- Создаем сопрограмму и "опросом" управляем ее выполнением
local task = coroutine.create(сложная Задача)
Смысл: Код выглядит как обычный, линейный и "блокирующий", но на деле он асинхронный. Мозг читает его без напряжения.


Смысл 2: Архитектор - "Кооперативная многозадачность" и контроль.
------------------------------------------------------------
* Теория: Мы сами решаем, когда отдать управление.
* Смысл: Мы становимся архитекторами своего планировщика. Мы не зависим от прерываний по таймеру, а сами говорим: "Стоп, я сейчас подожду, а ты пока выполни что-то еще".
Код
-- Пул из нескольких "независимых задач", как вы и сказали
local tasks = {
    coroutine.create(function() ... end), -- Задача 1: загрузка контента
    coroutine.create(function() ... end), -- Задача 2: анимация UI
    coroutine.create(function() ... end), -- Задача 3: обработка ввода
}

-- Главный цикл "опросом" управляет всеми задачами
function главныйЦикл()
    while true do
        local всеЗавершены = true
        for i, co in ipairs(tasks) do
            if coroutine.status(co) ~= "dead" then
                всеЗавершены = false
                coroutine.resume(co) -- "Опрос" конкретной сопрограммы!
            end
        end
        если все Завершены then break end
    end
end
* Смысл: Мы точно знаем, в какой момент какая задача будет выполняться. Нет гонки данных, нет сложных примитивов синхронизации, как в потоках. Мы создаем детерминированную систему.


Смысл 3: Эффективность - эффективное ожидание и реактивность.
------------------------------------------------------------------------------------------------------
* Теория: Сопрограмма может быть приостановлена в любой точке.
* Смысл: Мы можем элегантно реализовать ожидание без блокировки всего приложения.
Код
-- В движке: ждем 2 секунды перед загрузкой данных.
function ждать(секунды)
    local времяСтарта = os.clock()
    while os.clock() - времяСтарта < секунды do
        coroutine.yield() -- "Спим", не блокируя основной поток, отдавая управление другим задачам
    end
end
* Смысл:** Мы пишем логику, которая "живет" во времени, но не замораживает весь мир вокруг себя. Это основа для AI, анимаций, диалогов в играх.


Смысл 4: Эффективность - генераторы и бесконечные последовательности.
------------------------------------------------------------------------------------------------------------------
* Теория: Сопрограмма может yield-ить промежуточные результаты.
* Смысл: Мы создаем "ленивые" вычисления и потенциально бесконечные потоки данных.
Код
function бесконечнаяПоследовательность(старт, шаг)
    local текущее = старт
    while true do
        coroutine.yield(текущее)
        текущее = текущее + шаг
    end
end

-- Создаем генератор чисел, начиная с 10, с шагом 5
local генератор = coroutine.wrap(бесконечнаяПоследовательность)
local gen = генератор(10, 5)

print(gen()) --> 10
print(gen()) --> 15
print(gen()) --> 20
-- Можно получать значения по требованию, не вычисляя все сразу.
* Смысл: Экономия памяти и вычислений. Мы рассчитываем следующее значение только тогда, когда оно реально нужно.

Итого. Вся прелесть — в этом "превращении". :smile:  Сопрограммы в Lua — это мост между двумя мирами:
1. Мир для программиста: Удобный, последовательный, понятный код.
2. Мир для машины: Гибкое, асинхронное, неблокирующее выполнение.

И ключ к управлению этим миром — наш "опрос" с помощью `coroutine.resume`. Это диалог: "Ты готова поработать?", "Сделай шаг", "Отдохни, я спрошу тебя позже".
Это и есть тот самый глубокий смысл, который делает сопрограммы в Lua таким элегантным и мощным инструментом.  
Два варианта использования графического пакета IUP (Lua 5.4) в QUIKе
 
От теории к смыслам! :smile:
Вся прелесть и заключается использования сопрограмм в превращении выполнения одной последовательной задачи луа в ряд независимых задач! Как добиваемся независимости, опросом сопрограмм, там где нужно и тогда когда нужно!

Вот мой рабочий пример (как есть прямо в таком виде сейчас крутится, это не образец для подражания,  :what: но), что я только с ним не делал? И сейчас на вечерней падает сопрограмма - обработка таблицы всех сделок, ну и ладно скрипт работает, а с вечеркой когда руки дойдут разберусь.
Код
function OnMain()

    Log:trace("OnMain started")
    
    -- Создаем корутины Прверка пароля
    local coPassword   = coroutine.create(checkPassword)
    
    -- Прверка пароля при первом входе!(корутина с безопасным вызовом)
    safe_resume(coPassword, "coPassword")

    --[[GUI.initialize()

    -- Создание таблицы ордеров
    GUI.createTable({
        name = "orders",
        title = "Active Orders",
        width = 1000,
        height = 400,
        x = 10,
        y = 50,
        columns = {
            {
                iCode = 1,
                title = "Time",
                par_type = QTABLE_TIME_TYPE,
                width = 120
            },
            {
                iCode = 2,
                title = "Price",
                par_type = QTABLE_DOUBLE_TYPE,
                width = 100
            },
            {
                iCode = 3,
                title = "Volume",
                par_type = QTABLE_INT64_TYPE,
                width = 100
            }
        }
    })
    
    -- Создание информационной метки
    GUI.createLabel({
        id = "statusLabel",
        text = "System Status: OK",
        x = 10,
        y = 10,
        width = 300,
        color = "#00FF00",
        bgColor = "#333333"
    })
    --]]

    GUI.initialize()
    -- Создание таблицы ордеров
    GUI.createTable({
        name = "orders",
        title = "Активные ордера",
        columns = {
            {
                iCode = 1,
                title = "Время",
                type = QTABLE_TIME_TYPE,
                width = 120
            },
            {
                iCode = 2,
                title = "Операция",
                type = QTABLE_STRING_TYPE,
                width = 100
            },
            {
                iCode = 3,
                title = "Объем",
                type = QTABLE_INT_TYPE, -- Теперь правильно QTABLE_INT_TYPE = 1
                width = 80
            }
        }
    })

    -- Пример использования в главном цикле
    local hook = PerformanceHook()
    --local performanceHook = PerformanceHook()

    local fatal = nil

    AutoUpdateVersion()
    CreateWindowRobot()

    if Start ~= nil then
        Start()
    end

    AtExit(function()
        for _, so in pairs(SmartOrder.pool) do
            so:enough()
            so:process()
        end
    end)

    if Robot ~= nil then -- Провека на наличие основтой функции

        ---- функция для получения информации о классе 
        local ClassInfo = getClassInfo(class_names[1]);
        firmid = ClassInfo and ClassInfo.firmid or ''; Log:trace('firmid = ' .. tostring(firmid ) );
        
        -- Создаем корутину для функции Robot
        local routine = coroutine.create(Robot) 
        Log:trace("Robot started")
        
        -- Создаем корутины
        --local coPassword   = coroutine.create(checkPassword)
        local coConnection = coroutine.create(checkConnection)
        local coTradeDate  = coroutine.create(checkTradeDate)
        local coServerTime = coroutine.create(checkServerTime)
        local coWorkTime   = coroutine.create(checkWorkTime) -- Сопрограмма для отслеживания рабочего времени 
        --local coStopTimeTrading = coroutine.create(checkStopTimeTrading)

        -- Cоздание корутин для стратегий реального времени
        --if not rejime.test and event_co.connected == 1 and event_co.servertime[2] and flagTimeTrading then
            -- Cоздание корутины function 
            local coCapitalManager = coroutine.create(CapitalManagerCo--function() CapitalManagerCo(CONFIG) end
            )
            local coMoneyManagement = coroutine.create(function()
              --for _, class in ipairs(class_names) do
                --for n, symbol in ipairs(symbol_names) do  
                    --if mm[class][symbol] ~= nil then
                        --MoneyManagementCo( mm[class][symbol] )
                        MoneyManagementCo( firmid, account, class_names, symbol_names )
                    --else
                        --Log:error("MoneyManagement instance 'mm[n]' is nil. Cannot start MoneyManagementCoroutine.")
                    --end
                --end
              --end
            end)

        --if not rejime.test and event_co.connected == 1 and event_co.servertime[2] and flagTimeTrading then
            local co_alltrade = coroutine.create(alltrade_processor)
            local co_order_book = coroutine.create(order_book_processor)
            --local co_tt_parametrs = coroutine.create(trade_data_processor)
            
            local futuresCoroutine = coroutine.create(futures_position_processor)
            local futuresLimitCoroutine = coroutine.create(futures_limit_processor)
        --end
        
           
        while WORKING_FLAG do

            --------------------------
            local sek = os.clock();
            --------------------------

            --[[-- Обновление данных
            --GUI.update_connection_status(isConnected())
            --GUI.update_last_activity(os.time())
            --GUI.update_uptime(getUptime())

            -- Добавление новых ордеров
            --while hasNewOrders() do
            --    GUI.add_order(getNextOrder())
            --end

            -- Обновление торговой панели
            GUI.updateComponent("trading_panel", {
                {"BUY", 100.50, 10},
                {"SELL", 101.00, 5}
            })

            -- Добавление метки на график
            GUI.Chart.addLabel("MAIN_CHART", "Support Level", {
            YVALUE = 98.50,
            COLOR = RGB(46, 204, 113)
            })--]]

            -- Обновление данных
            GUI.updateTable("orders", {
                {os.date("%H:%M:%S"), "BUY", 10},
                {os.date("%H:%M:%S"), "SELL", 5}
            })

            -- Запуск корутин с безопасным вызовом
            if not rejime.test then

                safe_resume(coConnection, "coConnection")
                SetCell(table_id, 1, 1, tostring(event_co.connected == 1 and 'Connect' or 'NoConnect'))

                if event_co.connected == 1 then

                    safe_resume(coTradeDate,  "coTradeDate")
                    safe_resume(coServerTime, "coServerTime")
                    safe_resume(coWorkTime,   "coWorkTime")
                    --safe_resume(coStopTimeTrading, "coStopTimeTrading")

                    --if event_co.connected == 1 then
                    -- Запуск корутины MoneyManagement
                    --safe_resume( MoneyManagementRoutine, "MoneyManagementRoutine")
                    safe_resume( coCapitalManager, "coCapitalManager")
                    --end

                    -- Запускаем корутину (История сделок и стакан)
                    --Log:info('tradedate[1] =' ..tostring(event_co.tradedate[1]) ..'; worktime =' ..tostring(event_co.worktime[2]) ..'; servertime[2] =' ..tostring(event_co.servertime[2]) --..'; flagTimeTrading =' ..tostring(flagTimeTrading) )
                    
                    if event_co.tradedate[1] 
                    and event_co.worktime[2]
                    and event_co.servertime[2] 
                    then
                        safe_resume(co_alltrade, 'co_alltrade')
                        safe_resume(co_order_book, 'co_order_book')
                    end

                    --coroutine.resume(co_tt_parametrs)
                    -- Функция для запуска корутины
                    --start_futures_position_processing(futuresCoroutine)
                    --start_futures_limit_processing(futuresLimitCoroutine)

                    safe_resume(futuresCoroutine, 'futuresCoroutine')
                    --safe_resume(futuresLimitCoroutine, 'futuresLimitCoroutine')
                end

                -- Формирем модуль СМ
                --safe_resume( coCapitalManager, "coCapitalManager")
                --safe_resume( coMoneyManagement, "coMoneyManagement")
            end

            -- co Robot Затем используйте его методы
            local res, errmsg = coroutine.resume(routine)
            
            if not res then
                fatal = "Broken coroutine (Robot): " .. errmsg
                -- Вариант 1: Использование глобального обработчика (рекомендуется)
                _G.global_error_handler:handle_error(fatal, "Robot")
    
                -- Вариант 2: Статический вызов
                -- ErrorHandler.handle_error_static(fatal, "Robot")
                break
            end

            if coroutine.status(routine) == "dead" then
                Log:trace("Robot routine finished")
                break
            end
           
            ProcessRegistered()

            --local elapsed_ms = performanceHook(sek) -- sleep(1000)
            hook(sek)  -- Обновляем метрики

            sleep(spinner.config.interval * 1000)  -- Контроль частоты

            --if rejime.test then 
            --    sleep(100)
            --else
            --    Log:trace(math.floor(1000 - tonumber(elapsed_ms)))
                --sleep(  )
            --    sleep(1000)
            --end
        end
    end

    if Stop ~= nil then Stop() end
    ProcessAtExit()  -- Вызов ProcessAtExit
    ErrorCollector.log_all_errors()  -- Логирование всех ошибок при завершении
    Log:trace("Robot stopped")
    
    if fatal ~= nil then
        error(fatal)
    end
end
Как использовать Lua библиотеку визуального интерфейса IUP внутри корутин (coroutines)?
 
Насколько понял Вашу задачу. Задача заключается в том, чтобы использовать IUP с корутинами в Lua, чтобы интерфейс не блокировал основной поток выполнения программы, а позволял продолжать выполнение других операций в программе, пока окно IUP остаётся открытым. Возможно этот пример подойдет, нужно проверять, но разобраться поможет. Удачи.
Код
require "iuplua"

-- Указываем глобальный атрибут для работы с корутинами
iup.SetGlobal("IUPLUA_THREADED", "YES")

-- Функция для создания диалога с текстовым полем
function create_input_dialog()
    local text = iup.text{expand = "HORIZONTAL", value = ""}
    local ok_btn = iup.button{title = "OK", size = "50"}
    local cancel_btn = iup.button{title = "Cancel", size = "50"}
    
    local dlg = iup.dialog{
        iup.vbox{
            iup.label{title = "Введите текст:"},
            text,
            iup.hbox{ok_btn, cancel_btn}
        },
        title = "Ввод данных",
        size = "300x100"
    }
    
    return dlg, text, ok_btn, cancel_btn
end

-- Функция для асинхронного ввода через корутину
function async_input(coroutine_fn)
    return function(...)
        local co = coroutine.create(coroutine_fn)
        local success, result = coroutine.resume(co, ...)
        return result
    end
end

-- Основная функция диалога как корутина
function input_dialog_coroutine()
    local dlg, text, ok_btn, cancel_btn = create_input_dialog()
    
    -- Создаем promise-like объект для синхронизации
    local result = { waiting = true, value = nil }
    
    -- Callback для OK
    ok_btn.action = function()
        result.value = text.value
        result.waiting = false
        return iup.CLOSE
    end
    
    -- Callback для Cancel
    cancel_btn.action = function()
        result.value = nil
        result.waiting = false
        return iup.CLOSE
    end
    
    -- Показываем диалог (не модальный!)
    dlg:show()
    
    -- Ждем завершения в цикле (можно заменить на более изящное решение)
    while result.waiting do
        coroutine.yield()  -- Отдаем управление обратно
        iup.LoopStep()     -- Обрабатываем события IUP
    end
    
    dlg:destroy()
    return result.value
end

-- Пример использования в основном потоке Quik
function main()
    print("Начало работы скрипта")
    
    -- Запускаем диалог в корутине
    local co = coroutine.create(input_dialog_coroutine)
    
    -- Основной цикл обработки
    local timer = os.clock()
    while coroutine.status(co) ~= "dead" do
        -- Периодически возобновляем корутину
        if os.clock() - timer > 0.1 then  -- каждые 100 мс
            local success, input_text = coroutine.resume(co)
            if success and input_text then
                print("Пользователь ввел: " .. input_text)
                break
            elseif not success then
                print("Ошибка в корутине:", input_text)
                break
            end
            timer = os.clock()
        end
        
        -- Здесь может выполняться другой код
        -- Например, обработка данных из Quik
        process_quik_data()
        
        -- Небольшая пауза чтобы не грузить CPU
        os.execute("ping -n 1 127.0.0.1 > nul")  -- для Windows
        -- os.execute("sleep 0.1")  -- для Linux
    end
    
    print("Скрипт продолжает работу после диалога")
end

function process_quik_data()
    -- Здесь может быть код для работы с данными Quik
    -- который выполняется параллельно с открытым диалогом
end

-- Запуск основной функции
main()
Как использовать Lua библиотеку визуального интерфейса IUP внутри корутин (coroutines)?
 
Ростислав Дм. Кудряшов, Редко кто использует такой подход, посмотрите вот работу возможно она поможет Вам разобраться:  BetterQuik - intraday trading framework;  © 2017 Denis Kolodin; https://github.com/BetterQuik/framework. На мой не компетентный взгляд это лучшее что есть.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Модернизация инвестиционного портфеля (Рефакторинг кода). Или почему нельзя путать скальсперские или внутридневные стратегии с инвестициями. Спекуляция против инвестиции (Speculation versus investment).

Пару слов про свою задачу. Есть не просто старый, а древний портфель ИИС, для анализа и выработки решений используется тайм фрейм месячный, это основной, изредка опускаешься для детализации на недельный, ну а для входа раз в год бывает уточняешь H4. Так как т. ф. месячный, то тренд классический в 12 бар равен периоду 1 год. Наблюдать ежедневно за таким подходом означает 365 раз заснешь. Поэтому здесь важно отслеживать не которые реперные точки, и получать сигнал.

Это масштабы "Крупных денег", глобальных игроков, и здесь прекрасно работает классический тех. анализ. А Волатильность в 1 стандартное отклонение, сообщает о возможных изменениях на месяц. Делая вход в позицию, рассматриваешь месячный горизонт как минимум. Торгуя руками психологически не комфортно "скакать" по разным т. ф. сюда нужно добавить что инвестиционный портфель нужно диверсифицировать, иногда хеджировать, а если несколько портфелей? Как тут проводить разбалансировку?

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

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

А вот размер нужно считать, это одна из основных задач рефакторинга, это прежде всего про эффективность позиции на месяцы и в целом про эффективность инвестиции. Вот и обозначен основной вопрос инвестиций!
Ошибка при поиске пиков\впадин кастом индикатора
 
Вроде все правильно работает.  :!:  Вот результаты теста в SciTe:
Код
RingBufferClassOPP.lua"  1  
Функциональный стиль:
Последнее значение:   100
Предпоследнее:   90
Первое в буфере:   30

Все элементы (новые сначала):
100
90
80
70
60
50
40
30

ООП стиль:
RSI   1   период назад:   45
RSI   2   период назад:   36
RSI   3   период назад:   50
RSI   4   период назад:   46
RSI   5   период назад:   54
Среднее RSI:   46.2

Анализ ADX:   Слабый тренд или флэт
Функциональный стиль:   0.43   сек
ООП стиль:   0.631   сек
>Exit code: 0    Time: 1.483
Страницы: Пред. 1 2 3 4 5 6 7 8 9 10 11 ... 27 След.
Наверх