Кубик "Period Statistic"

Кубик предоставляет разного рода статистику, которой имхо не хватает в ТСЛаб:
=============================================================================

• отображает доходность стратегии в расчете на период (год, месяц). Доходность отображается как в процентах, так пунктах. На мой взгляд, доходность разных периодов для возможности корректного сравнения должна считаться в процентах за период, т.к. цена инструмента изменяется, порой значительно, соответственно, сравнивать условные 10 пунктов доходности при цене инструмента 20 пунктов и при цене инструмента 40 пунктов - некорректно, именно поэтому настройка "База расчета" по умолчанию установлена для расчета именно процентов. Настройка "Период расчета" по умолчанию установлена в "Год". На график доходности выведен график инструмента, который позволяет сравнивать доходность с состоянием рынка в этот период, по умолчанию график инструмента окрашен в черный цвет. Для тех, кто использует черную тему ТСЛаб имеется настройка "Цвет свечей графика", где можно выбрать более комфортный цвет отображения графика инструмента.
• отображает просадку кривой эквити в днях по каждому периоду просадки, максимальную зарегистрированную просадку в днях и общее накопленное значение кол-ва дней просадки в днях. Данный параметр позволяет сравнить стратегии между собой по кол-ву дней, когда наблюдалось просадка эквити. Данные выведены на график. Просадка как и доходность в настоящий момент считается от фиксированной прибыли за соответствующий период (расчет не фиксированной прибыли в текущее версии пока не производится, т.к. довольно серьезно нагружает систему, в будущем будет добавлен после оптимизации расчета). Просадка рассчитывается следующим образом: в случае если предыдущее значение эквити больше, чем текущее значение, то начинается отсчета баров просадки, как только кол-во времени, между барами равняется одним суткам, то считается, что просадка просуществовала один день. Расчет каждого периода просадки ведется вплоть до момента пока эквити не превысила ранее достигнутое значение. Максимальная просадка рассчитывается как максимально достигнутая продолжительность просадки по всем периодам. Общая продолжительность просадки, соответственно, как сумма продолжительности просадок по всем периодам.
• производит расчет гладкости эквити вдоль медианы, то есть рассчитывает насколько кучно результаты работы стратегии располагаются вдоль ее медианы, чем данный коэффициент ниже, тем эквити наиболее точно повторяет медиану. Расчет производится по кривой фиксированной прибыли. Чем выше коэффициент, тем менее гладкой будет эквити вокруг своей медианы. В случае если эквити нулевое, либо отрицательное, то коэффициент не рассчитывается и устанавливается в значение 100.000, в случае если по данному набору параметров при оптимизации нет ни одной сделки, то коэффициент устанавливается в значение 200.000, сделано это для того, чтобы наиболее плохие результаты при сортировке всегда располагались в конце списка и на них не надо было останавливать свое внимание.
  По умолчанию в расчет принимаются только те значения, которые ниже медианы, т.к в большинстве случаев именно этот параметр наиболее интересен для анализа. Если необходимо анализировать разброс значений эквити в обе стороны от медианы, то необходимо отключить опцию "Использовать значения ниже медианы", в этом случае в расчет будут приниматься значения по обе стороны от медианы, что покажет общую кучность результатов вокруг нее.
  Настройка "Период PTMKoef" устанавливается в днях, отвечает за качество измерения данных, то есть задает период между расчетными точками для контроля отклонения кривой эквити от медианы в днях, по умолчанию 7 дней. Настройка сделана для целей уменьшения нагрузки на ПК и увеличения скорости расчетов. На медленных ПК необходимо увеличивать данную настройку до получения приемлемых результатов (стоит понимать, что чем больше установлено данное значение, тем хуже будет результат измерения). В случае установки значения, меньше чем 7 или большего, чем 50% от кол-во дней в загруженной истории, автоматически применяется 7.
  Для возможности оценки разных стратегий между собой когда медиана одной стратегии начинается с нулевой точки в левой стороне графика доходности, а медиана другой - с какого-то отрицательного значения все медианы приводятся к нулевой точке, то есть по-простому сдвигаются в нулевую точку вместе с образующей медиану эквити, в этом случае можно говорить об идентичности расчета и сравниваемости показателей. Для целей отключения данного механизма имеется настройка "Рассчитывать когда медиана выше нуля", при установке данной опции расчет оценки ровности будет производиться только в том случае, если медиана выше нулевого значения доходности, когда медиана ниже нуля, то расчет не производится. Побочным эффектом такого расчета будет то, что системы, которые определенное время находились в просадке и их медиана не поднималась выше нуля будут ранжированы выше (то есть получат более низкий коэффициент), чем если бы ранжировалось на "общих основаниях", т.к. в этом случае их негативный период попросту не анализируется. В отдельных случаях оценка может наоборот ухудшиться, т.к. в расчет будет получен только период когда медиана была выше нуля, в котором будет большое количество просадок.
• рассчитывает коэффициент MAR, то есть отношение максимальной просадки эквити в процентах к среднегодовой доходности, данный коэффициент важен с точки зрения определения риска за получение единицы профита. Рекомендуемые большинством источников для дневных и среднесрочных стратегий значения: "минимум" от 1.5, "оптимально" от 2.0, "идеально" от 3.0. В настоящий момент коэффициент рассчитывается как как общая среднегодовая доходность, деленная на максимальную просадку, рассчитываемую платформой ТСЛаб. В будущем расчет будет несколько переделан на получение значений доходности/просадки за каждый расчетный период и их усреднения за время работы стратегии.
• рассчитывает коэффициент WLBarsRatio, как отношение средней продолжительности выигрышных и проигрышных сделок. Данный коэффициент характеризует стратегию с точки зрения одного из "основных правила" трейдинга "Режь убытки, дай прибыли течь", добавлен в расчет по мотивам прочтения статьи "Грааль не нужен!" на "Смартлабе".

Примечания:
===========

• Данные по кубику отображаются в дополнительном окне в виде графиков, в результатах оптимизации в виде дополнительных столбцов окна оптимизации, в коне "Результаты" в разделе "Пользовательские".
• Окно, выводимое кубиком удобно располагать в какой-либо части экрана под основным штатным окном "Доход", таким образом можно удобно просматривать параметры работы стратегии за текущий период. Есть один нюанс ТСЛаб, о котором имеется тикет в тех.поддержке: при настроенном расположении окон если в скрипте при запуске ТСЛаб или нажатии кнопки "Сохранить и выполнить" имеется ошибка сборки, то настроенной расположение окон сбивается. Это "особенность" платформы ТСЛаб, которая в будущее, вероятно, будут поправлена.
• Кубик собран для тестирования стратегий на одном инструменте, под стратегии на двух и более инструментах пока не было необходимо, как такая необходимость наступит, то соответствующий функционал будет добавлен.
• Код кубика к настоящему посту не прикладывается, т.к. кубик еще в процесс доработки и код надо причесать (оптимизировать, что-то переписать в более лаконичные формы, убрать ненужные комменты и т.д.), как кубик приобретет окончательную форму, то код также будет выложен.
• Расчет коэффициентов при оптимизации можно отключить сняв соответствующие галочки в настройках кубика.
• Настройка "Показывать графики эквити" включает отображение в окне графиков панели эквити. В настоящий момент выводится только эквити, рассчитанная на основании фиксированной прибыли. Особого практического интереса не представляет, т.к. полностью повторяет соответствующую кривую базового функционала платформы ТСЛаб. Для чего сделана: в дальнейшем будут добавлены расчеты: эквити на основе внутренней нормы доходности (почитать можно по ссылкам: Как правильно рассчитать доходность?, Внутренняя норма доходности, РАСЧЕТ IRR В EXCEL ), которая будет корректной в том числе в случае работы с блоком изменения позиции, эквити БайЭндХолд, которая будет рассчитываться исходя из фактической "загрузки" денежных средств в тестируемой стратегии в соответствии с реальной используемой лотностью и начальным депо, расчет эквити фиксированной прибыли в процентах и т.д. О проблемных местах в расчетах платформы ТСЛаб можно почитать по ссылкам в группе ТСЛаб в телеграм: расчет показателей и блок изменения позиции, расчет результатов стратегии.
• Какие-либо доработки делаются на основе личного энтузиазма в изучении тематики, поэтому добавлен только используемый мною функционал. Все дальнейшие мысли будут также добавляться в функционал кубика. Если есть какие-то идеи, просьба писать в посте, общими усилиями можно собрать неплохой инструмент для тестирования.

Общая информация по доп.кубикам:
================================
Для корректной работы кубика необходимо в папку Handlers также поместить общую библиотеку для кубиков. Библиотека содержит методы логирования, расчета и т.д., которые применяются в разных кубиках, поэтому весь этот функционал вынесен в отдельную dll, чтобы не повторяться и всегда иметь "свежие" версии кода
побарный (не потоковый) кубик: https://docs.tslab.pro/pages/viewpage.action?pageId=38961293
папка Handlers и создание индикаторов на API: https://docs.tslab.pro/pages/viewpage.action?pageId=20185716

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

За выгрузку отвечает опция "Выводить в Excel расчет PTMKoef Calculation".



Выгрузка тестовых данных осуществляется в 3 файла формата Excel. Папка для выгрузки "C:\TSLabStats", если на Вашей машине нет такой папки, то она будет создана.



После выгрузки 3 файла необходимо прислать для анализа любым удобным способом: либо на электронку gaa8008_собака_gmail_точка_com, либо в телеграмм в личку: @AleksandrGanov. По тестовым данным уже можно будет что-то сказать почему так получается и внести правки (при необходимости) в алгоритм расчета.

Примечания:
===========

• для выгрузки в эксель в папку Handlers необходимо поместить библиотеку EPPlus (сайт разработчика библиотеки по ссылке)
• выгрузка Не производится при оптимизации и в режиме Агента, то есть получить данные можно только при запуске пересчета в режиме лаборатории
• для значений PTMKoef 1000 и 2000 выгрузка расчета не осуществляется
• для выгрузки тестовых данных необходимо обновить библиотеку gaaCommon_ServiceLib.dll, т.к. в нее добавлены методы печати таблиц данных

Доделан функционал расчета доходности в процентах годовых на основании средневзвешенной суммы в рынке

Что это такое и где об этом почитать написано в самом первом посте на настоящему кубику, в дополнение привожу еще несколько статей:

• УК "Арсагера". Как рассчитать доходность?
• Money-weighted Rate of Return
• What is XIRR vs IRR in Excel
• 11 способов расчета доходности

Что изменилось в кубике:
===============================

• Так как настроек кубика уже довольно внушительное кол-во, то все настройки распределены по группам, чтобы было проще ориентироваться
• убран вывод эквити по закрытым сделкам, т.к. это былf тестовая кривая, которая полностью повторяла штатную с вкладки "Доход"
• добавлена опция "Вывод в оптимизацию: AWAProfit" (AWA - Average Weighted Assets). При установленной опции в процессе оптимизации рассчитываются параметры доходности по средневзвешенной стоимости активов, в оптимизацию выводится доходность в процентах годовых за каждый календарный год тестируемого интервала. Необходимо понимать, что параметр показывает доходность, приведенную к годовым значениям, то есть если стратегия за 1 день получила прибыль 1%, то это равносильно годовой доходности 365%, при этом если тестируемый период до года, то расчет производится линейным методом, если тестируемый период более 365 дней, то расчет производится с учетом ежегодного реинвеста. Линейный метод: прибыль в процентах делится на кол-во дней ее получения и умножается на 365, например, 1%, заработанный за 5 торговых дней равен ежегодной доходности 1%*(365/5) = 73% годовых. С реинвестом доход считается по формуле (1+1%) в степени 365/5, то есть показывает сколько процентов было бы заработано, если бы темп получения прибыли оставался прежним, и при этом сумма постоянно реинвестировалась, в данном случае - это 100% годовых
  
  
• добавлена опция Показать панель "Доходность % годовых по периодам". При установке опции выводится панель доходности по периодам в процентах годовых. Данная панель отображает 2 графика: доходность средств, вложенных в тестируемую стратегию и доходность средств, вложенных в стратегию \"Бай Энд Холд\" на тестовом интервале. Обе кривые рассчитываются на основании средневзвешенной стоимости активов в рынке, при этом для стратегии "Бай Энд Холд" начальный депо определяется из размера средств, необходимых на фактическое совершение первой сделки, то есть стоимость активов + комиссия на вход на свече совершения первой сделки по цене Open. При расчете кривой "Бай Энд Холд" не используется настройка лаборатории \"начальный депо\", т.к. расчет производится на основании фактического кол-ва средств, требуемых для для тестируемой стратегии. Фактически в результате на графиках имеет место сравнение доходности рынка и доходности действий трейдера на этом рынке. Также на график выводятся 2 линии: это доходность рынка и доходность действий трейдера (стратегии) за весь тестируемый исторический период.
  В чем основное отличие от доходности, рассчитываемой ТСЛаб? Платформа рассчитывает доходность на основании CAGR, который не учитывает время вложения средств, фактическое кол-во вложенных средств, изменение кол-ва вложенных средств в процессе исполнения стратегии, фактическое время нахождения денежных средств в рынке, то есть по-простому, данный показатель рассчитывает не эффективность капитала, а скорость роста кривой эквити. Рассчитываемые ТСЛаб и кубиком показатели будут до определенной точности равны только при соблюдении всех условий: 1. работа одним лотом или указание в настройках платформы корректной суммы начального депозита, то есть если мы собираемся открыть сделку на 2 лота, то депозит должен быть указан в размере не менее двух лотов + комиссия на вход; 2. в процессе исполнения стратегии ни в один момент времени не должно быть превышения фактически располагаемой суммы. Превысить довольно легко, например, можно указать начальный депозит 100.000, но при этом на первой же сделке приобрести 500 лотов фьючерса на RTS и платформа без проблем даст это сделать, однако при расчете показателей доходности цифры будут совершенного некорректными, т.к. начальный депозит 100.000, а полученная доходность в разы превосходит реальную возможную сумму в силу того, что фактически покупка была совершена в тех объемах, которых у трейдера попросту не было. Расчет доходности на основании AWA лишен этого недостатка, т.к. считает доходность исходя из фактических объемов и времени сделок.
  Основное отличие: текущий кубик рассчитывает эффективность вложения денежных средств с точки зрения фактических сумм и времени нахождения в рынке, платформа ТСЛаб рассчитывает скорость роста кривой эквити. При правильных настройках платформы оба расчета будут совпадать с определенной точностью, но это не обязательное условие, например, разница может быть в том, что платформа ТСЛаб считает вход в рынок с момента окончания настройки "Торговать с бара", кубик рассчитывает вход в рынок с бара фактического входа в рынок.
  
  
• добавлена опция "Тесты: Выводить в Excel расчет AWAProfit". При установленной опции при пересчете скрипта в папке "C:\TSLabStats\" будут созданы 4 файла формата Excel, в которых будут содержаться данные по расчету доходности на основании суммы средневзвешенных активов, то есть доходности с учетом фактического нахождения денежных средств в рынке. Денежные средства считаются находящимися в рынке полный торговый день, если в этот день был хотя бы один вход, все движения внутри дня суммируются в общий итог по внесению и по выводу средств (по покупке и продаже активов). Расчет доходности по средневзвешенным суммам более корректно отображается годовую ставку доходности по используемым средствам, в том числе в целях сравнения с доходностью рынка - кривая "БайЭндХолд". Примечания: для выгрузки в эксель в папку Handlers необходимо поместить библиотеку EPPlus, сайт разработчика: epplussoftware.com; выгрузка Не производится при оптимизации и в режиме Агента, то есть получить данные можно только при запуске пересчета в режиме лаборатории.
  
  

Для понимания того, что находится внутри Excel-файлов приводится настоящая методика расчета
===========================================================================================

Термины и определения

• операционная дата - дата, в которую была какая-либо операция в рынке, либо дата начала периода, на которую происходит перенос открытых позиций с прошлого операционной даты, либо дата окончания периода, на которую производится фиксация финансового результата по закрытым и/или открытым позициям - далее по тексту "ОперДата". Термин "Операционный день" не используется, т.к. фактически рынки могут работать круглосуточно, поэтому ОперДата в данном контексте наиболее удачное определение конкретного периода в 24 часа.
• операционный период - кол-во полных дней с окончания прошлой ОперДаты до конца текущей ОперДаты, то есть включая текущую ОперДату - далее по тексту "ОперПериод".
• расчетный период - период времени, за который определяется доходность в процентах годовых: весь тестовый исторический период, месяц, год
• Date - ОперДата
• LastBar - номер последнего бара ОперДаты
• MoneyIn - Общая сумма денежных средств поступившая в рынок в связи с открытием длинной/короткой позиции (включая комиссии)
• MoneyOut - Общая сумма денежных средств полученная с рынка в связи с закрытием длинной/короткой позиции (за минусом комиссий)
• MoneyInFact - сумма денежных средств фактически поступившая в рынок в связи с открытием длинной/короткой позиции (включая комиссии). Более детальная информация указана в описании расчета AccumOperSum

Для упрощения расчетов принимается следующие допущения:

• время вклада/изъятия денежных средств внутри ОперДаты не учитывается, вклад денежных средств в рынок считается совершенным в начала ОперДаты, а изъятие денежных средств считается произведенным в момент окончания ОперДаты. Имеющиеся и/или вложенные на начало ОперДаты денежные средства сохраняются до ее окончания и изымаются только в конце ОперДаты, то есть фактически принимается допущение, что все входы в позицию осуществляются в начале ОперДаты, а выход из позиций - в конце ОперДаты, равно как и имеющиеся на начало ОперДаты открытые позиции считаются действующими до конца ОперДаты
• бОльшая точность до движений внутри дня по задумке автора не требуется, точность расчета доходности на основании удержания денежных средств в течение одного дня вполне удовлетворяет необходимой цели расчета - получение оценки фактической эффективности использования денежных средств с учетом времени их удержания в рынке в пересчете на процент годовых
• инфляция денежных средств за время исторического периода не учитывается
• расчет производится для условных единиц стоимости инструмента, выражаемых в платформе ТСЛаб в пунктах без учета фактической стоимости пункта и/или изменения курса условной единицы стоимости за время теста на историческом периоде

Расчетные величины:

• DayBalance - сальдо ден.потоков ОперДаты. Равно разности вложенных и изъятых с рынка денежных средств в ОперДату
• AccumDayBalance - накопительный итог на момент окончания каждой ОперДаты. Рассчитывается как накопительный итог DayBalance всех ОперДат до текущей, включая DayBalance текущей ОперДаты, то есть сальдо за несколько ОперДат с начала расчетного периода и до текущей ОперДаты включительно
• OperBalance - сумма денежных средств в рынке на конец прошлого ОперПериода, которая используется в текущем ОперПериоде, то есть фактически это остаток в рынке после окончания прошлого ОперПериода, который сохраняется в рынке до окончания текущего операционного периода. Рассчитывается как сумма прошлого операционного дня + DayBalance текущего дня
• Trades - количество трейдов в течение ОперДаты. Под трейдом понимается любой изменение позиции, будь то вход в позицию, выход из позиции или изменение размера позиции посредством блока "изменить по", либо через API
• Days - продолжительность ОперПериода в днях. Продолжительность ОперПериода считается нулевой, если в этом периоде OperBalance имел нулевое значение , т.к. фактически в рынке не было никакой суммы. При этом, если в финальную дату ОперПериода было внесение денежных средств, что будет отражено в графе MoneyIn, то продолжительность данного ОперПериода будет равна одному дню, т.к. в этом случае внесенные денежные средства в начале финальной ОперДаты ОперПериода в соответствии с принятыми допущениями по расчету отработают ровно один день
• AccumDays - накопительное кол-во дней всех ОперПериодов, величина, необходимая для расчета средней ежедневной суммы в рынке на протяжении расчетного периода, рассчитывается как сумма продолжительности всех ОперПериодов с начала расчетного периода
• AccumOperSum - накопительная операционная сумма (далее - ОперСумма) с начала расчетного периода. Рассчитывается как сумма ОперСумм каждого ОперПериода, которые в свою очередь рассчитываются как OperBalance*Days + MoneyInFact, то есть общая сумма всех денежных средств ОперПериода за каждую ОперДату.
• MoneyInFact - это сумма, которая дополнительно поступила в рынок на начало ОперДаты (с учетом допущения о вносе всех средств на начало ОперДаты) к сумме, имеющейся в рынке на конец предыдущего ОперПериода. Рассчитывается следующим образом:
  • если в ОперДату MoneyIn=0, то MoneyInFact=0
  • если в ОперДату имеется только одна операция и это операция внесения, то MoneyInFact=MoneyIn;
  • если в ОперДату имеется больше, чем одна операция MoneyInFact считается исходя из фактической очередности поступления/изъятия денежных средств по номерам баров внутри ОперДаты, в итоге получая фактическую сумму внесение денежных средств к сумме на конец предыдущего ОперПериода. Разницы MoneyInFact и DayBalance в том, что DayBalance фактически это сальдо дебетового и кредитового оборота ОперДаты, а для расчета эффективности с учетом принятых допущений требуется узнать именно сумму, которая была дополнительно внесена на начало ОперДаты, чтобы обеспечить нужный оборот внутри дня, то есть фактически это сальдо оборотов поступления и изъятия до бара последнего поступления, остальной оборот изъятия для данного расчета не учитывается. Если сальдо получится отрицательным, то MoneyInFact приравнивается к нулю, т.к. по сути все внесенные на ОперДату средства были предварительно взяты из рынка и дополнительный вклад не делался, но при этом если первая или первые операция (операции) были операцией внесением средств, то MoneyInFact будет равен сумме этой операции даже при отрицательном сальдо, т.к. чтобы обеспечить открытие позиций в этот день трейдер должен был добавить в рынок дополнительные средства, что учитывается данным расчетом
• PosCost - стоимость открытых позиций на последний бар ОперДаты. Рассчитывается как произведение кол-во лотов открытых позиций, размер лота и цены закрытия последнего бара ОперДаты. В случае если на конец общей тестируемой истории имеется открытая позиции, то она будет фиктивно в расчетных целях считаться закрытой, в строке закрытия данной позиции будет указано "HystoryEnd", соответственно, стоимость такой позиции будет равна нулю
• Profit - прибыль в пунктах на конец ОперДаты. Рассчитывается PosCost - AccumDayBalance, то есть стоимость позиций на текущую минус накопительный итог на ОперДату
• ProfitPctAnn - доходность денежных средств в расчетном периоде в пересчете на процентов годовых исходя из фактической средневзвешенной суммы в рынке в течение расчетного периода. Показывает фактическую доходность денежных средств (с учетом допущения об инфляции ДС), использованных в стратегии.

ПРИМЕЧАНИЯ:
============

• расчет работает только для одного инструмента, стратегии с несколькими инструментами будут показывать неверные данные. Для этих целей кубик не писался, т.к. у автора кубика отсутствуют соответствующие потребности
• для выгрузки в эксель в папку Handlers необходимо поместить библиотеку EPPlus, сайт разработчика: epplussoftware.com или взять приложенную к настоящему посту dll
• тестирование было произведено на нескольких скриптах, в том числе с пересчетов в Excel вручную, при наличии ошибок просьба написать в личку (координаты выше в посте)

По просьбам трудящихся добавлен параметр "База приведения доходности, дней". В данном поле указывается параметр приведения доходности, в базовом варианте доходность приводится к 365 дням в году. При желании можно указать любое число (минимум 1, максимум 365). Если указать числа за пределами данного диапазона, то будет использована верхняя или нижняя граница соответственно

Спасибо

Спасибо большое Александр за вашу работу!
Подскажите планируете ли реализацию работы кубика на секундном таймфрейме?

PTMKoef выводится в результаты оптимизации при снятой галке

проверил по коду и в ТСЛаб версии 2.1.12.0 - снял галку, ничего не выводится, ставим выводится. Возможно у Вас какая-то более ранее версия и там (но это не точно, могу ошибаться) после изменения параметров кубиков перед оптимизацией надо было обязательно выполнить скрипт, чтобы параметры "закрепились", только потом оптимизировать. В текущей версии все без проблем работает. Привожу строку кода, она не будет по-другому работать даже если очень захотеть

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

Произведены следующие доработки:

• обновлена сервисная библиотека: добавлен метод-расширение по расчету стандартного отклонения данных коллекции. Имеется расчет в двух режимах: отклонение от среднего значения в обе стороны (как при расчете коэффициента Шарпа) и отклонение от среднего значения только в сторону ниже среднего значения (как при расчете коэффициента Сортино). Можно было бы использовать отличную библиотеку математических расчетов для C#, но это потребует добавления дополнительных DLL в папку Handlers, поэтому был добавлен самописный метод, чтобы не превращать использование кубика в процедуру с дополнительными сложностями.
• добавлена настройка "Вывод в оптимизацию: PeriodsData". При установленной опции в оптимизацию выводятся параметры на основании тестов каждого временного периода:
  • процент положительных периодов из общего числа протестированных периодов,
  • средняя доходность в пунктах и процентах,
  • максимальная просадка в пунктах и процентах,
  • среднее кол-во сделок,
  • уточненный коэффициент MAR,
  • стандартное отклонение доходности по периодам,
  • стандартное отклонение доходности по периодам в "отрицательную сторону" (сторону ниже среднего значения выборки),
  • коэффициент риска (по сути коэф. Шарпа, рассчитанный на основании данных каждого тестового периода),
  • просадка кривой доходности, то есть не так просадка, что считает платформа, а именно просадка доходности без учета начального депо - характеризует свойство системы "терять" накопленную доходность, рассчитывает на основании стандартного отклонения только в область отрицательных значений
    
    
    
    Просадки и доходности по периодам считаются корректно в независимости от указания начального депо, расчет использует фактическое начальное депо, требуемое для открытие необходимого кол-ва сделок на каждом из тестируемых периодов. В настоящее время в качестве периодов используются только года. Данные переходных между периодами сделок не учитываются, то есть параметры перформанса стратегии с текущим набором параметров считаются по фактически совершенным в течение тестируемого интервала сделкам, в связи с чем рекомендуется для теста использовать кубик CloseEveryPeriod чтобы учитывать внутри периода "цельные" сделки, то есть которые и открылись и закрылись внутри периода.
    
    
    
    В данном случае есть еще один положительный момент, выражающий в том, что все периоды будут протестированы независимо друг от друга, каждый со своими сделками без переноса сделок на другой период, в общем случае данный тест является одним из видов кросс-валидации на разных периодах, когда параметры подбираются на одном периоде и тестируются на другом.
• добавлена настройка "Настройки PeriodsData: Вывод PL за каждый период". При установленной опции в оптимизацию будут выведены данные по PL за каждый период. По умолчанию опция снята. При снятой опции "Вывод в оптимизацию: PeriodsData" данная настройка не имеет значения - данные не выводится.
• добавлена настройка "Настройки PeriodsData: Вывод PL% за каждый период". При установленной опции в оптимизацию будут выведены данные по PL% за каждый период. По умолчанию опция снята. При снятой опции "Вывод в оптимизацию: PeriodsData" данная настройка не имеет значения - данные не выводится.
• добавлена настройка "Настройки PeriodsData: Вывод MaxDD за каждый период". При установленной опции в оптимизацию будут выведены данные по MaxDD за каждый период. По умолчанию опция снята. При снятой опции "Вывод в оптимизацию: PeriodsData" данная настройка не имеет значения - данные не выводится.
• добавлена настройка "Настройки PeriodsData: Вывод MaxDD% за каждый период". При установленной опции в оптимизацию будут выведены данные по MaxDD% за каждый период. По умолчанию опция снята. При снятой опции "Вывод в оптимизацию: PeriodsData" данная настройка не имеет значения - данные не выводится.
• добавлена настройка "Настройки PeriodsData: Вывод кол-ва сделок за каждый период". При установленной опции в оптимизацию будут выведены данные по количеству сделок за каждый период. По умолчанию опция снята. Примечание: здесь необходимо помнить, что в каждом периоде учитываются только те сделки, которые были открыты и закрыты внутри данного периода, переходные сделки не учитываются. Полное описание данного момента приведено в описании настройки "Вывод в оптимизацию: PeriodsData". При снятой опции "Вывод в оптимизацию: PeriodsData" данная настройка не имеет значения - данные не выводится.
  
  Пример вывода детальных параметров по периодам:
  
  

Примечания:
===========

• При включении каждой настройки по выводу данных в оптимизацию следует ожидать увеличения общего времени оптимизации в силу присутствия намного бОльшего кол-ва расчетов. Где можно было оптимизировать расчеты - это сделано, использованы, в том числе, рекомендации документации платформы ТСЛаб. На тестах загрузка процессора ровная в пределах 100% с небольшими просадками, то есть явных огрехов в оптимизации использования ресурсов не имеется, но при появлении новых мыслей в код будут вноситься изменения и дополнения.

Произведены следующие доработки:

• добавлены улучшение и оптимизации по коду, подправлены незначительные нюансы в расчетах;
• добавлена настройка AWA Profit: Учитывать при расчетах резерв стратегии. При включении данной опции при расчет AWA-доходности будет учитываться фактически необходимый резерв на стратегию, то есть денежные средства, которые фактически будут пролеживать без "работы", обеспечивая резерв по максимальной просадке. Максимальная просадка считается исходя из максимальной просадки в пунктах (точно также как это делает платформа ТСЛаб), но с некоторым особенностями, в частности, если 2 просадки в пунктах будут одинаковыми, то в расчет примется та просадка, где будет минимальная оперсумма интервала, если оперсуммы одинаковые, то берется та просадка, где относительное значение будет больше. Под оперсуммой в данном случае понимается средняя сумма удерживаемых позиций на конкретном интервале просадки, т.к. именно эта сумма образовала конкретную величину падения в пунктах. Дополнительно при установке данной опции в результаты оптимизации выводится коэффициент пересчета просадки, который приводит необходимый запас к величине входа на дату запуска стратегии, например, оперсумма, вызвавшая падение 200 пунктов была равно 500 пунктов при цене инструмента 100 пунктов, то есть в среднем на интервале падения удерживалось 5 лотов инструмента; так как сама логика стратегии не поменялась, то данный сценарий с таким количество лотов инструмента также может повториться в будущем, НО т.к. цена инструмента будет другая, например, 300 пунктов, то просадка в пунктах будет также другая. В идеале осуществлять этот пересчет на каждом входе, но т.к. это технически накладно и не всегда легко реализуемо, то будет уместным использовать коэффициент пересчета просадки хотя бы на момент пуска стратегии в рынок и периодически в будущем при обслуживании стратегии. В вышеприведенном примере когда инструмент подорожал в 3 раза, то просадку следует ожидать в пунктах в 3 раза выше, соответственно, будет разумных и резерв под нее заложить бОльший c учетом приведенной к текущей цене инструмента оперсуммы;
• добавлена настройка AWA Profit: Коэффициент резерва по просадке. Данная настройка задает размер резерва денежных средств по просадке, например, максимальная просадка была 300 пунктов, соответственно, минимальная сумма депо для входу в позицию должна быть не меньше, чем Коэффициент резерва по просадке * размер просадки + рабочий лот на вход * цена инструмента, такой размер рассчитывается для того, чтобы при получении максимальной просадки, которая была зафиксирована на историческом тестировании был запас депозита на вход по стратегии для продолжения торговли. По умолчанию коэффициент запаса равен 2-м. В случае, если коэффициент установлен в значение больше 5, то будет использовано 5, в случае если установлено значение меньше нуля, то будет использовано значение по умолчанию 2;
• добавлена настройка Просадки: Тип отображаемой просадки (%, абс.значение). Задает тип отображаемой просадки на диаграмме просадок: в процентах или в абсолютных значениях. Просадка считается с момент ее возникновения и до момента перезаписи эквити нового хая. Позволяет наглядно ознакомиться с местами возникновения просадок и их размерами. По умолчанию считается в процентах. Просадка считается по кривой нефиксированной прибыли на общем интервале, то есть даже при разбиении интервалов просадка будут считаться по общему интервалу, при этом в результатах оптимизации за максимальную просадку будет взята максимальная из полученных на общем интервале или на каждом отдельно, то есть если на разбитых интервалах в 2015-м году была получена просадка 12%, но при этом если считать общую эквити эта же просадка к общей эквити будет равна 7%, то в результатах оптимизации будет выведено 12%, т.к. трейдер изначально не знает момент своего входа и если система уже показывала 12%, то это может повториться в будущем, поэтому берется максимально зафиксированная просадка. В этом случае диаграмма может показывать 7%, но в оптимизации будет использовано значение 12%;
• добавлена настройка Просадки: Не рассчитывать при оптимизации. При установке данной опции в процессе оптимизации не рассчитываются кривые просадок, соответственно, не используются показатели maxDD, maxDDPct, ddToOSRatio, MaxDDDays, DDDurDays. При расчете максимальных просадок по периодам используются просадки периодов и не сравниваются с просадками на общем тесте. Отключение расчета указанных показателей значительно экономит время оптимизации. По умолчанию опция выключена.
• добавлена настройка Просадки: Выводить в режиме агента. При установленной опции панель выводится в режиме агента. По умолчанию установлено в False для уменьшения нагрузки на железо;
• добавлена настройка Настройки PeriodsData: Минимальный % дней в последнем периоде. Данная настройка определяет минимальный процент от общего кол-ва дней последнего тестируемого интервала, чтобы данные этого периода были приняты в расчет показателей. Значение по умолчанию 80%, то есть период должен содержать минимум 80% от тестируемого интервала, чтобы его данные были приняты в статистику. При необходимости учитывать последний период в любом случае значение настройки устанавливается в ноль.
  Особенности:
  -- в независимости от установленной настройки просадка последнего года всегда учитывается в полном объеме" +
  -- в случае, если последний интервал по длительности дольше, чем установленная настройка, то данные этого интервала НЕ приводятся к общей продолжительности интервала, то есть учитываются в фактически полученных значениях, т.к. будущее неизвестно и экстраполировать текущие данные на весь интервал не является обоснованными. Например, если период годовой, но прошло лишь 85% от года, то данные прошедших 85% процентов года буду учтены в качестве годовых, как если бы эти данные были получены за весь период. В идеале вообще не учитывать последний период, если по продолжительности он не совпадает с выбранным тестируемым периодом, но чтобы посмотреть влияние последнего периода 80% в общем случае достаточная статистика, для уточнение поведения системы на последних данных. Для уменьшения данного эффекта и более точного использования последних данных можно использовать полугодовой интервал (в данный момент иные интервалы, кроме годовых недоступны - находятся в процесс доработки).

Примечания:
============
-- чем больше расчетов, тем мощнее нужен компьютер, включение в состав скрипта данного кубика по тестам может замедлять оптимизацию по времени от 3-х до 10 раз
-- кубик выкладывается as is, то есть используется на личное усмотрение. Перед публикацией соответствующих доработок они проверяется на нескольких скриптах с ручным пересчетом в Эксель, однако, это не исключает того, что где-либо могут быть нюансы. Если что-то заметили, что на Ваш взгляд считается или работает неверно, просьба писать либо на электронку gaa8008_собака_gmail_точка_com, либо в телеграмм в личку: @AleksandrGanov.

Приветствую!
Александр, подскажите, что означают значения DDToOSRatio, TradeMaxLoss, RF и как они рассчитываются?
Можно ли исключить вывод данных значений в оптимизацию?

Доброе! Действительно не указал сам термин, только описал его суть в посте выше со слов "Дополнительно при установке данной опции в результаты оптимизации выводится коэффициент пересчета просадки.....". То есть это коэффициент, показывающий какую максимальную просадку допускает инструмент на тесте на 1 пункт операционной суммы на интервале падения. По-простому: средняя сумма на интервале падения была 1000 пунктов, например, 2 условных лота по 500 пунктов, просадка при такой сумме составили 154 пункта, таким образом, на 1 единицу суммы в рынке система допустила падение 154/1000 = 0.154 пункта. Так как цена инструмента и объем входа меняется, а сама суть системы - нет, то разумно полагать, что при большей сумме входа (больше лотов или большая цена инструмента) можно ожидать бОльшую максимальную просадку. Например, входим теми же 2 лотами, но инструмент уже стоит 750 пунктов, соответственно, средняя сумма на интервале падения будет 1500 пунктов (это очень упрощенно, т.к. при расчете коэффициент считается средневзвешенная сумма, то есть средняя сумма исходя из фактического кол-ва лотов и дней их удержания на всем интервале падения), следовательно, можно ожидать максимального падения 1500*0,154 = 231 пункт.
Почему возникла идея сделать этот коэффициент: при тестировании максимальное падение в пунктах могло быть, например, в 2014-м году когда инструмент стоил 100, а сегодня он стоит, 430. На мой взгляд, неуместно использовать значение просадки в пунктах, полученное в том историческом периоде с той ценой инструмента для формирования резерва под вход в сегодняшней дате. Для целей пересчета как раз можно использовать данный коэффициент.

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

По "RF" - это Recovery Factor (фактор восстановления). ТСЛаб рассчитывает свой фактор, я для своих целей считаю уточненный фактор исходя из рассчитанной максимальной просадки. При расчетах обратил внимание, что просадка в пунктах в ТСЛаб не всегда совпадает с тем, что рассчитывает кубик, хотя по идее должна совпадать, т.к. рассчитывается от одной и той же кривой нефиксированной прибыли, почему так происходит выяснять не стал, просто проверил свой расчет и считаю свою просадку и от нее RF, зачастую расчетная в кубике получается больше, чем то, что считает ТСЛаб. Выберу время сравню по каждому бару почему так получается, и выложу сравнение. Разница не большая, но она есть, поэтому использую то значение, где просадка больше.

Насчет запрета вывода в оптимизацию - не делал, если очень докучают можно просто скрыть столбцы и сохранить данную настройку по умолчанию

Добрый день!
Александр в последней и предпоследней версии версии вашего кубика просадка в днях стала рассчитываться не верно.
В версии от 31.03.21г считается более менее правильно согласно эквити.
Прилагаю рисунок эквити, где видно, что максимальная просадка равна 2 мес - 55дня.
В последней версии вашего кубика просадка выдается 115 дней, а в версии от 31.03.21г - 55 дней.
Скрины прилагаю.

добрый день

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

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

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