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

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

Если задача показать разные методы, то проще дать ссылку на статью, где все они формализованы. Сейчас все разучились искать, так что я прямо обратно в 94-ом, когда интернет был набором каталогов с ссылками.

                                                                          «Всё новое — хорошо забытое старое».

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

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

Из за сложности  редактирования кода, все мои скрипты не подходили. Вспомнил про старые сохранённые работы, от группы "Универ". Основная идея у ребят, была делать простые торговые роботы, доступные для понимания с минимальной подготовкой в области программирования и знаний луа.

Один из таких я взял за основу. Источником рыночных данных выступает функция getCandlesByIndex. Здесь все вроде бы просто, определяем идентификатор графику и читаем любые данные с графиков.
Таким подходом давно не пользовался, более того избегал его, а причина заключалась в способности скрипта обрушить целиком весь терминал. Квик просто падал.

Каково же было мое удивление, когда набросав с десяток индикаторов (в том числе и самописных), получив с них данные и еще с десяток тайфреймов получив свечи, что это все это аккуратно работает!

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

Основной из них, функция getCandlesByIndex предоставляет возможность, получить массив из таблиц данных из свечей, либо таблицу одной свечи, что здесь оптимальной и надежей?
* Первый уменьшает количество обращений к терминалу, следовательно уменьшает нагрузку.
* Второй безопасней исключает "дыры".

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

Добрый день Nikolay,  но в моем варианте думаю отрисовка меток, вариант еще проблематичной. А этот в режиме ADVISER такой эксперт, в режиме связанных окон корректно переходит с с инструмента на инструмент. Да с задержками но в мое случае приемлемо. Начинаю   читать с месячного тф. и заканчивает или 15 или 5 минутными свечами. Смущает Вот такая запись?А именно цикл проверки и ожидания?

Но ведь есть принципиальное отличие, и оно накладывает свой отпечаток на проверки.
Если в CreateDataSource получаем только интерфейс на получение данных и ждем загрузку с сервера тех самых данных. То в этом подходе можем допустить даже return.
В варианте с getCandlesByIndex читаем свечи уже загруженные в терминал, и все что беспокоит это "дыры" в данных?

Я написал основные проблемы при чтении с графика. И это только самые очевидные. Дыры - это не проблема, т.к. обрабатываются точно также. Плюс удобство работы вызывает сомнения, т.к. чтобы эта конструкция работала необходимо держать открытыми графики. У меня скрипты могут сканировать до 1000 инструментов на разных ТФ - предлагаете все это открывать, наносить индикаторы. Терминал умрет первым.

И в подходе с CreateDataSource, как уже обсуждали, нет никаких бесконечных циклов ожидания. Точно также - заказ, и сразу возврат. А фоне висит задача проверки загрузки данных. И все это будет работать в пустом терминале, не не открыто ни одно окно, за ненадобностью.

Если думаете, что getCandlesByIndex не требует ожидания и проверки, что данные есть, то ошибаетесь. Точно также требует. Да, если скрипт запускается уже после того как терминал загрузился и "прогрелся", то можно ожидать, что данные уже есть. Но полностью исключает вариант работы скрипта "не выключаясь". А с таким числом требуемых графиков, терминал будет стартовать долго.

Делаю так:local I = getNumCandles(tag.price) - это ведь по сути индекс, но и количество полученных свечей.

График для каждого ТФ. (свой tag) для одного тикера.
Так как я не представляю портфель с 1000 тикеров, такой просто будет ломать мой риск менеджмент (а он еще участвует в расчёте количества в удерживаемой позиции). То задачу сканирования 1000 тикеров вижу только для предварительного отбора инструментов. Ну или как ранее здесь предлагалось, ждать какой "стрельнет". Но это все не про эффективность использования капитала.
Вывод, только ликвидные, фундаментально подтвержденные инструменты. А их на нашем рынке раз два и обчёлся.
А пробежаться глазами раз в недельку по рынку и портфелю, очень полезно, мне так просто необходимо.

Дело здесь вот еще в чем, подход Score - позволяет оценивать качество самого сигнала, это уже не просто данные индикаторов, это класс сигнала, определяющий качество + количество принятия торгового решения. Что позволяет перейти  от подхода написания "торгового робота", к  уровню проп-деск-алгоритма, а не просто сканирования розничных индикаторов, и полной автоматизации самого процесса торговли. Также это один из путей быстрого бек теста в квик, правда здесь возникает другая проблема, синхронизации данных.  

А причем здесь портфель? Это чисто техническая задача - получение данных баров для инструмента. Их можно получить из Квика, можно через API биржи, из других ресурсов, даже из своего кеша, чтобы каждый раз не делать запрос на все данные, ради одного нового бара.

Но если она решается через получение данных с открытого графика, то это накладывает условия для работы - необходимо открыть график для каждого ТФ, каждого инструмента.

Если даже инструментов 10 и три ТФ, то это 30 открытых графиков с назначенными идентификаторами. И все это руками. И нельзя ничего с этими графиками сделать в процессе работы скрипта.
Очень странное решение при наличии независимого источника данных, не требующего никаких условий, кроме наличия потока от брокера по инструменту.

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

Nikolay,  про существующие недостатки данного подхода получения данных (getCandlesByIndex), Вы все правильно говорите. К Вашим замечаниям лишь добавлю, что ошибки в коде при использовании этого подхода, часто приводят к вылету (падению) самого терминала. Для меня это была основная причина по которой его не применял.

Но у метода есть и положительные стороны для его использования, часть из которых уже назвали, просто зафиксируем:

1. Простота реализации идей.
2. Быстрота реализации целых стратегий и идей.
3. Наглядность, легкая отрисовка результатов на графике, поддержка множественности линий.
4. Легко тестировать стратегии, легко менять целиком парадигмы (1 ТФ так вообще без вопросов).
5. Минимальная подготовка в знаниях языка, при этом можно строить целые торговые роботы.

Минимум времени затраченного от идеи до ее реализации и получению результатов! Это пожалуй ключевые моменты для применения подхода в своих скриптах.

О применении подхода: 1 инструмент, к нему графики необходимых тайм фреймов + режим связанных окон, не нужно хранить 30 графиков. Да не немного инженерии требуется, при определении смены инструмента, но это совсем просто, и это, все та же техническая задача получения данных.

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

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

Тогда получается что можно этот единый подход? Подход "Логика Обработки Данных из Интерфейса"?  

Подход, разделяем получение данных и их обработку.

1. Задача на получение данных создает источник и регистрирует его в менеджере.
   
2. Задачи на обработку данных берут источник из менеджера и работают с ним через единый интерфейс.
   

За основу таблицы-прототипа для представления данных в едином виде, напрашивается подход реализованный CreateDataSource - "Функция предназначена для создания таблицы Lua и позволяет работать со  свечками". То есть по индексу свечи  возвращать соответствующее значение?

Идея объединить все эти источники под единый интерфейс на первый взгляд очень хороша и удобна, поскольку позволяет работать с данными с разных источников одинаково. Но, учитывая особенности Квик, а именно отсутствие синхронизации данных, не известно что и когда получишь, страшно выкладывать получившийся класс.

Посмотрим асинхронный подход ранее здесь обсуждаемый, может там что то по проще проявится?

 У баров есть единое пространство - это время. Индекс бара ничего не говорит, он не подходит для этих целей. Поэтому синхронизировать данные необходимо по шкале времени наименьшего ТФ или по наибольший общий делителю. При этом, т.к. бары могу быть построены по любым данным, то и ТФ может быть любым, например 30 секунд. В итоге, определяем квант времени, а далее по мере прихода данных происходит их обработка.
При этом если есть ТФ не кратные друг другу, то обработка может быть не синхронной, например бары 2 и 3 минуты. Будут моменты когда приходит бар 3 минуты, а бара 2 минуты нет и не будет в это время.

Ничего сверхъестественного. По большому счету это, то как глазами видят картину. Смотрим на графики и видим текущее состояние (или сдвинув графики на точку времени) и производятся действия в этой точке времени. Синхронизация не зависит от Квика и его особенностей. Представьте, что одновременно обрабатываете данные из Квика или API MOEX, API NYSE, API LME и API SEHK. Совершенно разные источники, разные соединения, разные задержки. И при этом работать же надо, а не говорить - это сложно, не будем.

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

Более важен вопрос - а надо ли это делать. Банально иногда нет причин. Выбрали один источник данных, с помощью которого получаете 90% данных, и реализовать работу с ним. А если надо будет получать данные иначе, ну добавите несколько методов, чтобы считать через него. У меня в скриптах внутри Квика все получается через CreateDataSource. Иногда через таблицу сделок для ТФ меньше минуты. Или чтение из csv файлов. Все это загоняется в простейшую таблицу у которой __index может ссылаться на ds, если он есть. И реализованы простейшие прокси методы повторяющие методы ds из CreateDataSource. Вот и есть универсальный контейнер. Если хотите использовать getCandlesByIndex - ничего не мешает, просто реализуйте методы O C H L Size Close. И получите единый интерфейс к данным. Но когда в скрипте нет задачи собирать данные, то проще и быстрее сделать напрямую. В конечном итоге - зачем выполнять лишний код.

Но, как написал выше - если это необходимо. Иногда все эти сказки из книг типа "Чистый код" - это теоретические изыскания, не имеющие никакого значения на практике, т.к. делают код очень медленным, объемным.

О чудеса чудесные! Вот какой вывод могу сделать, после всех моих изысканий. Формула QUIK - нативного кода. Если свести всё к одному правилу:

"Пиши Lua так, как будто это C-обёртка над QUIK API"

1. явные функции.

2. минимум таблиц.

3. минимум косвенности.

4. предсказуемый жизненный цикл.

Поэтому версия без метатаблиц — QUIK - нативная! Да уж, до экспериментировал. Где то это уже видел?

Оказывается, QUIK гарантирует, если время последней свечи изменилось — свеча закрыта! Тогда определяется ключевой элемент "детектор НОВОЙ СВЕЧИ".
Важно, торговые решения применяем, только после закрытия свечи, торговля внутри незакрытой свечи Запрещена!
Следящее правило, работать с 2–3 последними свечами, отсчет ведется от текущей не закрытой свечи.
Еще одно правило, так как QUIK не гарантирует синхронность и свеча может закрыться с задержкой, правильно: сравнение datetime свечи.
Правило уже озвучено зафиксируем, график = результат, Lua только читает.

Минимальная необходимая структура:
robot/
* main.lua
* Graph.lua
* NewBar.lua
* Trade.lua

Сам адаптер:Ну и пример того что получилось:

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

Если хотите полный контроль над данными и полную синхронность, то просто рассчитывайте бары сами. Берете таблицу обезличенных сделок, читаете и строите бары любых ТФ. При этом, т.к. поток для расчетов один, то и разные бары будут получены в одно время. Т.е. это уже часть вашей архитектуры, а не зависимость от API Квика. Более того, такой способ позволит получать много дополнительных метрик, которые просто не доступны для баров Квика. Собственно очень многие сторонние системы, подключающиеся к Квику, так и работают - расчет по сделкам, дамп закрытых баров в кеш (файлы, базы данных). В итоге данные на истории всегда есть, получаете только новые бары. Также такой подход позволит оценивать систему в любой выбранной точке на истории без необходимости что-то заказывать в Квике. А если это сторонняя система, то и не открывая Квик.

Этот мой пример вообще на "помойку" нужно выбросить, что и сделаем.

Индикатор, который управляет стопом, например по fractals,  скрипт всего 4КБ.  

Вы ошибаетесь.
Вот так получаете  class_code и sec_code и интервал: