Блог им. Dmi3

Управление портфелем торговых систем. А как это делаете вы?

Ооож
★6
75 комментариев
QuantAnalyzer4
avatar
Dmitriy, 
это платное ПО?
Дмитрий Овчинников, бесплатное с ограниченной функциональностью.
avatar
Dmitriy, я хоть и не Дмитрий, но скажу спасибо! Возможно это поможет и мне (они обещают удобное сравнение бэктеста и реальных результатов). 
avatar
Dmitriy, но надо сказать, бесплатная версия ниочем https://strategyquant.com/quantanalyzer/free/ 
  • Compare results: limited to the first 50 trades only
  • итд
    но за наводку спасибо! 
avatar
dip, 
скачал бесплатную, мне нравится, про 50 трейдов это сравнение с реальностью? Т
Сергей Сергаев, 
нет, все на формулах. Я понимаю, что могу написать макросы, но это не решит и половины проблем.
Софт с функцией портфельной оптимизации навскидку https://www.multicharts.com/features/portfolio-trading/#:~:text=Portfolio%20optimization%20lets%20you%20find,for%20both%20tasks%20with%20ease.

Ресерчить тоже можно не в Excel ;)
avatar
tashik, 
спасибо. 
С рисечем у меня проблем пока нет :)

tashik, 
в мультичат надо будет переписать туда все свои системы, чтобы воспользоваться его оптимизацией?
Дмитрий Овчинников, да. В Вашем случае QuantAnalyzer лучше будет, там даже плагин есть к MT4
avatar
tashik, 
MT4  у меня нет :) 
Спасибо, гляну внимательно на QuantAnalyzer
tashik, 
под MT5 тоже есть и после танцев с бубном даже работает!
Дмитрий Овчинников, класс)
avatar
1С и дописать все что нужно
avatar
Переходите от сделок к эквити по дням. 70 эквити — 70 столбцов. Расчет портфеля на VBA займет секунды. Программа оптимизации — минуты. Не лень будет — напишете обработчик на питоне, который берет данные из того же экселя. Просто и компактно.
avatar
SergeyJu, 
по дням меня категорически не устраивает. У меня половина систем быстрые, у них сделки длятся минуты. Делать одно решение для быстрых, другое для медленных, не мой путь.
Ну и даже если делать. 
200 торговых дней*50 систем*6 лет=60 тыс строк, такая же ерунда с количеством.
Дмитрий Овчинников,  «200 торговых дней*50 систем*6 лет=60 тыс строк»

200*6=1200 строк. VBA за секунды будет считать и намного больший объем если не построчно работать а обращаться к range.

На уровне портфеля подневная еквити по моему вполне достаточна.
Есть классическое решение konkop, там вообще списки трейдов грузятся и собирается портфель.
avatar
quant_trader,
А 70 систем куда делись? В столбцы? Так можно и дни в столбцы засунуть. Будет 6 строк. 
Дмитрий Овчинников, нет, так не получится. Будет 70 строк — подневная по каждой из 70.

Если брать подневные еквити то таблица будет 1200 дней * 70 столбцов (или строк) еквитей. Это смешной объем для VBA (при правильном подходе).

PS кажется понимаю — Вы собираете таблицу потом сортируете, это не выглядит оптимально.

Еще можно вообще при бектесте писать текстовую подневную еквити/или сделки в файл, потом в vba работать. Ексель мощная штука.
avatar
quant_trader,
Эта таблица все время меняется. Она не стационарная у меня. 
Дмитрий Овчинников, в подневных это так выглядит.

Сделали 70 бектестов, получили 70 еквитей. Они не меняются. Загрузили все 70 в столбцы. Посчитали портфельную еквити (vba или формула). Покрутили коэфициенты (вручную или оптимизатором), опять посчитали.

В последочных опять таки загрузили 70 списков трейдов. Отсортировали если надо (прямо в vba, не в таблице). Дальше этот список не меняется. Крутим коэфициенты, считаем.
avatar
quant_trader,
Сортирую я на отдельном листе, потом вставляю уже готовое в файл, иначе полдня пропало🤪
quant_trader, 
потратил все выходные на эксель: VBA, PowerQuiery, динамические таблицы  и пр.
Нифига не помогает, 70 тыс строк расчета нарастающего итога по промежуточным значениям убивают процессор в любом раскладе.

Похоже вы с SergeyJu правы, надо делать подневный тест и записывать данные систем в столбцы.
Вопросы с использованием капитала это конечно не закроет, зато можно будет добавить все быстрые системы, посмотреть на соотношение разных портфелей, правильное ли оно. Да и в медленных можно внутренние системы повытаскивать наружу, то есть анализировать не 50 систем, а фактические, которых там несколько сотен внутри.
Дмитрий Овчинников, это просто классическое решение для портфелей и Логунов ниже то же самое предложил.

«Вопросы с использованием капитала это конечно не закроет,»

Возможно и это решаемо. Если вместо столбцов еквити взять столбцы подневных % приращений еквити по каждой стратегии то там можно будет например не просто усреднять с весами а  например и суммировать приращения по пересекающимся стратегиям. Насколько я понимаю проблема в этом?
avatar
quant_trader,
Спасибо, я и так все суммирую конечно. А с капиталом на дневных нарезках конечно ничего не сделать, но это не беда, с капиталом я в старом файлео легко справлюсь, если удалю там расчёт итоговой эквити и просадка, ведь именно он тормозит. 
Добавлю к тому, что написали уважаемые коллеги: логичным кажется уходить в другие решения, но что бы продолжать еще какое-то время жить с текущим подходом, нужна агрегация. Если не подходит агрегация по дням, то можно агрегировать с меньшим ТФ, втч _отдельно_ (как и пишет SergeyJu) считать аллокацию капитала, вероятно используя времена в позиции (и, сооответственно, считать их пересечения, а не тащить все сделки). Можно это сделать в несколько итераций, написав рассчет/аггрегацию для 10 элементов, и выстроить иерархию — агрегируете данные для 10 систем, потом для 10 портфолио по 10 систем итд.  (Написав это, я бы еще раз сказал: надо уходить в другие решения)
avatar
SergeyJu, 
я кстати делал подобное, когда изучал корреляцию между отдельными системами.
Дмитрий Овчинников, Вы же на месяцы  портф собираете, не на полчаса. Поэтому подневная эквити — достаточно информативно для построения портфеля систем. 
В экселе штатный  размер листа  миллион. Я обычно беру 12 лет, как минимум. Примерно 3000 — 3500 длина столбца. Если число столбцов несколько сот — вообще не напряжно для расчетов. 
avatar
SergeyJu,
Я собираю портфель систем. Системы есть разные, но, практически у всех сделки внутри дня. У многих несколько сделок в разные стороны внутри дня. Портфельная тема инвестров в акции меня не устраивает. По меньшей мере потому, что общая сумма денег в системах существенно выше капитала и это тоже хочется считать. 
Дмитрий Овчинников, а, кажется понял почему подневные не подходят.
avatar
quant_trader, если быстрые системы торгуются с большими плечами, понятно, что возникают опасения, что совместные входы в одном направлении могут перегрузить ГО. 
Но я лично думаю, что мухи — отдельно, а котлеты должны быть отдельно. То есть контроль лимитов, грубый, можно сделать независимо от решения портфельной задачи. 
avatar
SergeyJu, я думаю в другом причина.
avatar
SergeyJu, 
сейчас и делается отдельно, но хочется это делать в одном и том же месте.
Сергей Сергаев, 
эксель в принципе понимает чуть более миллиона строк. Если я добавлю остальные портфели, то уже скоро упрусь в эту цифру :)
Дмитрий Овчинников, можно и больше 1М: www.masterdataanalysis.com/ms-excel/analyzing-50-million-records-excel/
avatar
Павел Ку, 
спасибо, вот это на самом деле востребованная тема!
Сергей Сергаев, 
то, что неэффективно, я и так понимаю. Но если задать ему оптимизацию, ему все равно придется все пересчитывать от и до на каждом проходе.
расскажи потом, к чему пришёл
avatar
а под волу нормируешь? типа если вола большая то и доха выше
имхо можно обойти проблему
просто разбив все на несколько групп

avatar
ves2010,
Если коротко, то нет. Длинно, не готов здесь и сейчас обсуждать
Дмитрий Овчинников, а мне просто лень
итак типа работает
avatar
ves2010,
Так у меня и так на три портфеля все разбито. Причём самая большая проблема с быстрыми. Там всего за год количество строк перерастает в проблему. 
ves2010, нормировка на волу сильно ухудшает многие трендовые системы. 
avatar
SergeyJu, нее… я имел ввиду результаты… эквити/волатильность_актива
avatar
Возможно, Питон подойдет с пакетом Pandas.
avatar
Питон и пандас
avatar
Eugene Logunov,
В этом и проблема, именно внутри дня бывают перегрузы по капиталу, причём регулярно.  Выбросы в эквити изредка, это меня меньше беспокоит. 

Пока хромаем с самодельным решением в самодельном тестере. Систем меньше чем у вас, и они все медленнее (Десятки тысяч сделок в бэктесте портфеля).

Не могу порекомендовать этот путь, но с ним можно почти все :) 

avatar
Eugene Logunov, любой язык высокого уровня справится, хоть тот же VBA. А вот насчет специализированных программ портфелей я как-то не уверен. По крайней мере все подходы на основе обращения ковариационной матрицы мне представляются заведомо опасными и я стараюсь с ними ничего общего не иметь.

avatar
Можно еще сделки по каждому алгоритму перевести в простое эквити (только не по дням, а минутки) и потом работать с ними как с «виртуальными тикерами». А тут уже поле для оптимизации богатое. Тот же мультичартс.
avatar
Eugene Logunov, 
спасибо, про Питон и R думаю, скорее про Питон, он более универсален, если уж изучать, то его.
Сейчас попробую все-таки найти специализированное решение, если разочаруюсь, буду делать на Питоне.
Дмитрий Овчинников, Питон просто модный ) 
avatar
Основной мой пойнт — переносить учёт трейдов и расчеты на sql-базу, а в экселе только анализ.
хочется как-то попытаться в автоматическом режиме пооптимизировать итоговые результаты, двигая параметры всех систем.

Это ведь классический curve fitting будет.

Поделюсь своим опытом, ТС он не подойдет, но может какую-то идею дать.
У меня (на данный момент) всего 8 ТС (было штук 15 максимум), торговля внутри дня. В натуре я могу переносить позиции на сл. день, но учитываю для анализа, что они закрыты.
Трейды вбиваю в БД исключительно «теоретические», т.е. результаты без проскальзываний (как положительных, так и отрицательных).
Каждая ТС имеет свой вес, в день могут быть открыты трейды по максимум 3 ТС — с наивысшим приоритетом.
Анализ веду в экселе. Не реже раза в неделю смотрю теоретический иквити, рез-ты (теоретические) по каждой ТС и меняю приоритеты и %риска на ТС.
Какие-то ТС периодически выпиливаются из эксплуатации, добавляются новые.

Важно: эксель фактически использую как толстый клиент, т.е. на VBA там наговнякано изрядно.
avatar
smooth_operator20, 
Это ведь классический curve fitting будет.

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

Выглядит именно так, что взять набор систем, набор параметров — и заоптимизировать их на истории по самое не могу.
avatar
smooth_operator20, 
по самые не могу я даже отдельные системы не оптимизирую. 
Простой пример: сейчас весь январь трендовые системы пилит. У многих трейдеров январь в минусе. У меня трендовые системы составляют часть общего портфеля, я в плюсе. Но вопрос, а не мало/много ли у меня трендовых систем в портфеле, решен на уровне здравого смысла. Здравый смысл в таких решениях всегда выдает не самое оптимальное решение. Я хочу по меньшей мере посмотреть весь диапазон возможных вариантов и результатов.
Дмитрий Овчинников, ок, тогда просто посмотри в сторону решения, когда факты хранятся в sql-базе, а анализ или прогон можно, наверное, и в пандасе делать, раз уж это стильно и молодежно))
Данные в экселе хранить, конечно, не вариант.
Ты и сам понимаешь.
С какими-нибудь знакомыми айтишниками в области обработки данных проконсультируйся.
PS Мне кажется, у тебя в таблице фактов полей мало.
Смотрел книжку «Статистика для трейдеров»? Там оч хорошая глава была, как трейды фиксить.
avatar
smooth_operator20, 
поля фактов ровно те, которые выдает стандартный отчет MT5.
Я даже не понимаю о чем речь, какие еще нужны исходные данные?

Дмитрий Овчинников, данные можно обогащать — это нормально))
Посмотри главу 13 книжки Булашев. Статистика для трейдера.
Особенно 13.8. Отчет о сделках. И 13.9 потом.
avatar
Соглашусь со стеком Python + pandas. То что векторизуется будет очень быстрым + с пандасом работать очень приятно, это как эксель на стероидах)). Ну а что не векторизуется — на голом питоне — даже в этом случае оно конечно мощнее, быстрее, чем эксель. Если питон с пандасом — сразу можно заценить Jupyter.
avatar
Replikant_mih, Вы про эксель или про VBA? 
Как-то мы пытались применить рэндом форест к ценовым рядам. Писал очень сильный парень, аспирант ВМК. Пока не применили оптимизацию вычислений и не переписали ядерные функции на Си, было ну очень тоскливо. Долго. До суток доходило. 

avatar

SergeyJu, Эмм, чёт я запутался). Про эксель — я про эксель без VBA. VBA, конечно, расширяет сильно возможности, но хз, мне кажется питон с пандасом и юпитером покруче будет).

 

Про си, рэндом форест и крутого аспиранта вообще не понял) — это аргумент в пользу того, что питон плох? Или эксель? Если питон… — зачем там писать рэндом форест, в том числе на си) — там же все написано давно). Не пойму короч). Если есть готовые с си под капотом либы на питоне — надо их юзать — удобно и быстро, если нет — уже по ситуации. На готовых либах рэндом форест — ну зависит от гипер-параметров и объема данных, если я много данных заряжу — будет долго, сутки — столько ни разу не заряжал)).

avatar
Replikant_mih, слов нет, питон круче. И библиотеки намного обширнее и современнее. Проблема в том, что «любой идиот» может присобачить библиотечку к импорту данных. А каменный-то цветок и не выходит. Отсюда возникают косые-кривые постановки задач, которые не ложатся на стандартные методы. И все, пиши сам на чем хошь. 
Насчет Си в Питоне. Стандартный технический прием по ускорению счета тяжелых задач — переписать ядерные функции на более быстром языке. Чтобы те 5% кода, которые забирают 90% вычислений считались раз в 30 быстрее.
avatar

SergeyJu, Понял теперь.

Ну, не знаю зачем что-то самому писать, в смысле из каких-то стандартных вещей — тот же случайный лес из примера. Его можно найти в нескольких реализациях сейчас — и sklearn и пайторчи-тензорфлоу тоже его реализовали, вроде, да и ещё наверняка много где — вроде даже есть реализации, задействующие возможности GPU)). Мы только на учебе в учебных целей для лучшего понимания писали на питоне реализации чего-то такого)).

 

Питон, конечно, очень медленный для таких вещей, но так никто его и не использует — именно из-за производительности. И да, C в помощь если надо что-то тяжелое замутить. Пробовал импортировать простенькие вычисления на C в питон, но для боевых задач не приходилось использовать этот подход пока.

avatar
В питоне иногда я использовал пакеты для ускорения расчетов либо cython, либо numba. Вроде очень хорошо ускоряет.
avatar
 Щас юзаю эксель все реже — не знаю, какую-то табличку завести, для расчетов — щас задумался — вообще не использую.
avatar
Eugene Logunov, объем работы на универсальных языках в разы больше. Но можно применить любой нестандартный метод. 
avatar

теги блога Дмитрий Овчинников

....все тэги



UPDONW
Новый дизайн