Переходите от сделок к эквити по дням. 70 эквити — 70 столбцов. Расчет портфеля на VBA займет секунды. Программа оптимизации — минуты. Не лень будет — напишете обработчик на питоне, который берет данные из того же экселя. Просто и компактно.
SergeyJu,
по дням меня категорически не устраивает. У меня половина систем быстрые, у них сделки длятся минуты. Делать одно решение для быстрых, другое для медленных, не мой путь.
Ну и даже если делать.
200 торговых дней*50 систем*6 лет=60 тыс строк, такая же ерунда с количеством.
Дмитрий Овчинников, «200 торговых дней*50 систем*6 лет=60 тыс строк»
200*6=1200 строк. VBA за секунды будет считать и намного больший объем если не построчно работать а обращаться к range.
На уровне портфеля подневная еквити по моему вполне достаточна.
Есть классическое решение konkop, там вообще списки трейдов грузятся и собирается портфель.
Сделали 70 бектестов, получили 70 еквитей. Они не меняются. Загрузили все 70 в столбцы. Посчитали портфельную еквити (vba или формула). Покрутили коэфициенты (вручную или оптимизатором), опять посчитали.
В последочных опять таки загрузили 70 списков трейдов. Отсортировали если надо (прямо в vba, не в таблице). Дальше этот список не меняется. Крутим коэфициенты, считаем.
quant_trader,
потратил все выходные на эксель: VBA, PowerQuiery, динамические таблицы и пр.
Нифига не помогает, 70 тыс строк расчета нарастающего итога по промежуточным значениям убивают процессор в любом раскладе.
Похоже вы с SergeyJu правы, надо делать подневный тест и записывать данные систем в столбцы.
Вопросы с использованием капитала это конечно не закроет, зато можно будет добавить все быстрые системы, посмотреть на соотношение разных портфелей, правильное ли оно. Да и в медленных можно внутренние системы повытаскивать наружу, то есть анализировать не 50 систем, а фактические, которых там несколько сотен внутри.
Дмитрий Овчинников, это просто классическое решение для портфелей и Логунов ниже то же самое предложил.
«Вопросы с использованием капитала это конечно не закроет,»
Возможно и это решаемо. Если вместо столбцов еквити взять столбцы подневных % приращений еквити по каждой стратегии то там можно будет например не просто усреднять с весами а например и суммировать приращения по пересекающимся стратегиям. Насколько я понимаю проблема в этом?
quant_trader,
Спасибо, я и так все суммирую конечно. А с капиталом на дневных нарезках конечно ничего не сделать, но это не беда, с капиталом я в старом файлео легко справлюсь, если удалю там расчёт итоговой эквити и просадка, ведь именно он тормозит.
Добавлю к тому, что написали уважаемые коллеги: логичным кажется уходить в другие решения, но что бы продолжать еще какое-то время жить с текущим подходом, нужна агрегация. Если не подходит агрегация по дням, то можно агрегировать с меньшим ТФ, втч _отдельно_ (как и пишет SergeyJu) считать аллокацию капитала, вероятно используя времена в позиции (и, сооответственно, считать их пересечения, а не тащить все сделки). Можно это сделать в несколько итераций, написав рассчет/аггрегацию для 10 элементов, и выстроить иерархию — агрегируете данные для 10 систем, потом для 10 портфолио по 10 систем итд. (Написав это, я бы еще раз сказал: надо уходить в другие решения)
Дмитрий Овчинников, Вы же на месяцы портф собираете, не на полчаса. Поэтому подневная эквити — достаточно информативно для построения портфеля систем.
В экселе штатный размер листа миллион. Я обычно беру 12 лет, как минимум. Примерно 3000 — 3500 длина столбца. Если число столбцов несколько сот — вообще не напряжно для расчетов.
SergeyJu,
Я собираю портфель систем. Системы есть разные, но, практически у всех сделки внутри дня. У многих несколько сделок в разные стороны внутри дня. Портфельная тема инвестров в акции меня не устраивает. По меньшей мере потому, что общая сумма денег в системах существенно выше капитала и это тоже хочется считать.
quant_trader, если быстрые системы торгуются с большими плечами, понятно, что возникают опасения, что совместные входы в одном направлении могут перегрузить ГО.
Но я лично думаю, что мухи — отдельно, а котлеты должны быть отдельно. То есть контроль лимитов, грубый, можно сделать независимо от решения портфельной задачи.
ves2010,
Так у меня и так на три портфеля все разбито. Причём самая большая проблема с быстрыми. Там всего за год количество строк перерастает в проблему.
Можно еще сделки по каждому алгоритму перевести в простое эквити (только не по дням, а минутки) и потом работать с ними как с «виртуальными тикерами». А тут уже поле для оптимизации богатое. Тот же мультичартс.
Основной мой пойнт — переносить учёт трейдов и расчеты на sql-базу, а в экселе только анализ.
хочется как-то попытаться в автоматическом режиме пооптимизировать итоговые результаты, двигая параметры всех систем.
Это ведь классический curve fitting будет.
Поделюсь своим опытом, ТС он не подойдет, но может какую-то идею дать.
У меня (на данный момент) всего 8 ТС (было штук 15 максимум), торговля внутри дня. В натуре я могу переносить позиции на сл. день, но учитываю для анализа, что они закрыты.
Трейды вбиваю в БД исключительно «теоретические», т.е. результаты без проскальзываний (как положительных, так и отрицательных).
Каждая ТС имеет свой вес, в день могут быть открыты трейды по максимум 3 ТС — с наивысшим приоритетом.
Анализ веду в экселе. Не реже раза в неделю смотрю теоретический иквити, рез-ты (теоретические) по каждой ТС и меняю приоритеты и %риска на ТС.
Какие-то ТС периодически выпиливаются из эксплуатации, добавляются новые.
Важно: эксель фактически использую как толстый клиент, т.е. на VBA там наговнякано изрядно.
В общем то все, чем мы занимаемся это curve fitting. Мы берем curve инструмента и вырезаем из него самые жирные куски. Чем плоха идея повырезать жирные куски из curve портфеля?
Конечно я не буду это делать бездумно, но немного оптимизации подключить хочется.
smooth_operator20,
по самые не могу я даже отдельные системы не оптимизирую.
Простой пример: сейчас весь январь трендовые системы пилит. У многих трейдеров январь в минусе. У меня трендовые системы составляют часть общего портфеля, я в плюсе. Но вопрос, а не мало/много ли у меня трендовых систем в портфеле, решен на уровне здравого смысла. Здравый смысл в таких решениях всегда выдает не самое оптимальное решение. Я хочу по меньшей мере посмотреть весь диапазон возможных вариантов и результатов.
Дмитрий Овчинников, ок, тогда просто посмотри в сторону решения, когда факты хранятся в sql-базе, а анализ или прогон можно, наверное, и в пандасе делать, раз уж это стильно и молодежно))
Данные в экселе хранить, конечно, не вариант.
Ты и сам понимаешь.
С какими-нибудь знакомыми айтишниками в области обработки данных проконсультируйся.
PS Мне кажется, у тебя в таблице фактов полей мало.
Смотрел книжку «Статистика для трейдеров»? Там оч хорошая глава была, как трейды фиксить.
Дмитрий Овчинников, данные можно обогащать — это нормально))
Посмотри главу 13 книжки Булашев. Статистика для трейдера.
Особенно 13.8. Отчет о сделках. И 13.9 потом.
Соглашусь со стеком Python + pandas. То что векторизуется будет очень быстрым + с пандасом работать очень приятно, это как эксель на стероидах)). Ну а что не векторизуется — на голом питоне — даже в этом случае оно конечно мощнее, быстрее, чем эксель. Если питон с пандасом — сразу можно заценить Jupyter.
Replikant_mih, Вы про эксель или про VBA?
Как-то мы пытались применить рэндом форест к ценовым рядам. Писал очень сильный парень, аспирант ВМК. Пока не применили оптимизацию вычислений и не переписали ядерные функции на Си, было ну очень тоскливо. Долго. До суток доходило.
SergeyJu, Эмм, чёт я запутался). Про эксель — я про эксель без VBA. VBA, конечно, расширяет сильно возможности, но хз, мне кажется питон с пандасом и юпитером покруче будет).
Про си, рэндом форест и крутого аспиранта вообще не понял) — это аргумент в пользу того, что питон плох? Или эксель? Если питон… — зачем там писать рэндом форест, в том числе на си) — там же все написано давно). Не пойму короч). Если есть готовые с си под капотом либы на питоне — надо их юзать — удобно и быстро, если нет — уже по ситуации. На готовых либах рэндом форест — ну зависит от гипер-параметров и объема данных, если я много данных заряжу — будет долго, сутки — столько ни разу не заряжал)).
Replikant_mih, слов нет, питон круче. И библиотеки намного обширнее и современнее. Проблема в том, что «любой идиот» может присобачить библиотечку к импорту данных. А каменный-то цветок и не выходит. Отсюда возникают косые-кривые постановки задач, которые не ложатся на стандартные методы. И все, пиши сам на чем хошь.
Насчет Си в Питоне. Стандартный технический прием по ускорению счета тяжелых задач — переписать ядерные функции на более быстром языке. Чтобы те 5% кода, которые забирают 90% вычислений считались раз в 30 быстрее.
Ну, не знаю зачем что-то самому писать, в смысле из каких-то стандартных вещей — тот же случайный лес из примера. Его можно найти в нескольких реализациях сейчас — и sklearn и пайторчи-тензорфлоу тоже его реализовали, вроде, да и ещё наверняка много где — вроде даже есть реализации, задействующие возможности GPU)). Мы только на учебе в учебных целей для лучшего понимания писали на питоне реализации чего-то такого)).
Питон, конечно, очень медленный для таких вещей, но так никто его и не использует — именно из-за производительности. И да, C в помощь если надо что-то тяжелое замутить. Пробовал импортировать простенькие вычисления на C в питон, но для боевых задач не приходилось использовать этот подход пока.
Где объемы?!? Где паника и массовый исход инвесторов?
Маркетос — совладелец биржи с долей больше 10% двигает бумагу по своим правилам и может рисовать абсолютно любой ценник. Жду появления на графи...
это платное ПО?
но за наводку спасибо!
скачал бесплатную, мне нравится, про 50 трейдов это сравнение с реальностью? Т
Ресерчить тоже можно не в Excel ;)
спасибо.
С рисечем у меня проблем пока нет :)
в мультичат надо будет переписать туда все свои системы, чтобы воспользоваться его оптимизацией?
MT4 у меня нет :)
Спасибо, гляну внимательно на QuantAnalyzer
под MT5 тоже есть и после танцев с бубном даже работает!
по дням меня категорически не устраивает. У меня половина систем быстрые, у них сделки длятся минуты. Делать одно решение для быстрых, другое для медленных, не мой путь.
Ну и даже если делать.
200 торговых дней*50 систем*6 лет=60 тыс строк, такая же ерунда с количеством.
200*6=1200 строк. VBA за секунды будет считать и намного больший объем если не построчно работать а обращаться к range.
На уровне портфеля подневная еквити по моему вполне достаточна.
Есть классическое решение konkop, там вообще списки трейдов грузятся и собирается портфель.
А 70 систем куда делись? В столбцы? Так можно и дни в столбцы засунуть. Будет 6 строк.
Если брать подневные еквити то таблица будет 1200 дней * 70 столбцов (или строк) еквитей. Это смешной объем для VBA (при правильном подходе).
PS кажется понимаю — Вы собираете таблицу потом сортируете, это не выглядит оптимально.
Еще можно вообще при бектесте писать текстовую подневную еквити/или сделки в файл, потом в vba работать. Ексель мощная штука.
Эта таблица все время меняется. Она не стационарная у меня.
Сделали 70 бектестов, получили 70 еквитей. Они не меняются. Загрузили все 70 в столбцы. Посчитали портфельную еквити (vba или формула). Покрутили коэфициенты (вручную или оптимизатором), опять посчитали.
В последочных опять таки загрузили 70 списков трейдов. Отсортировали если надо (прямо в vba, не в таблице). Дальше этот список не меняется. Крутим коэфициенты, считаем.
Сортирую я на отдельном листе, потом вставляю уже готовое в файл, иначе полдня пропало🤪
потратил все выходные на эксель: VBA, PowerQuiery, динамические таблицы и пр.
Нифига не помогает, 70 тыс строк расчета нарастающего итога по промежуточным значениям убивают процессор в любом раскладе.
Похоже вы с SergeyJu правы, надо делать подневный тест и записывать данные систем в столбцы.
Вопросы с использованием капитала это конечно не закроет, зато можно будет добавить все быстрые системы, посмотреть на соотношение разных портфелей, правильное ли оно. Да и в медленных можно внутренние системы повытаскивать наружу, то есть анализировать не 50 систем, а фактические, которых там несколько сотен внутри.
«Вопросы с использованием капитала это конечно не закроет,»
Возможно и это решаемо. Если вместо столбцов еквити взять столбцы подневных % приращений еквити по каждой стратегии то там можно будет например не просто усреднять с весами а например и суммировать приращения по пересекающимся стратегиям. Насколько я понимаю проблема в этом?
Спасибо, я и так все суммирую конечно. А с капиталом на дневных нарезках конечно ничего не сделать, но это не беда, с капиталом я в старом файлео легко справлюсь, если удалю там расчёт итоговой эквити и просадка, ведь именно он тормозит.
я кстати делал подобное, когда изучал корреляцию между отдельными системами.
В экселе штатный размер листа миллион. Я обычно беру 12 лет, как минимум. Примерно 3000 — 3500 длина столбца. Если число столбцов несколько сот — вообще не напряжно для расчетов.
Я собираю портфель систем. Системы есть разные, но, практически у всех сделки внутри дня. У многих несколько сделок в разные стороны внутри дня. Портфельная тема инвестров в акции меня не устраивает. По меньшей мере потому, что общая сумма денег в системах существенно выше капитала и это тоже хочется считать.
Но я лично думаю, что мухи — отдельно, а котлеты должны быть отдельно. То есть контроль лимитов, грубый, можно сделать независимо от решения портфельной задачи.
сейчас и делается отдельно, но хочется это делать в одном и том же месте.
имхо можно обойти проблему
просто разбив все на несколько групп
Если коротко, то нет. Длинно, не готов здесь и сейчас обсуждать
итак типа работает
Так у меня и так на три портфеля все разбито. Причём самая большая проблема с быстрыми. Там всего за год количество строк перерастает в проблему.
Пока хромаем с самодельным решением в самодельном тестере. Систем меньше чем у вас, и они все медленнее (Десятки тысяч сделок в бэктесте портфеля).
Не могу порекомендовать этот путь, но с ним можно почти все :)
Это ведь классический curve fitting будет.
Поделюсь своим опытом, ТС он не подойдет, но может какую-то идею дать.
У меня (на данный момент) всего 8 ТС (было штук 15 максимум), торговля внутри дня. В натуре я могу переносить позиции на сл. день, но учитываю для анализа, что они закрыты.
Трейды вбиваю в БД исключительно «теоретические», т.е. результаты без проскальзываний (как положительных, так и отрицательных).
Каждая ТС имеет свой вес, в день могут быть открыты трейды по максимум 3 ТС — с наивысшим приоритетом.
Анализ веду в экселе. Не реже раза в неделю смотрю теоретический иквити, рез-ты (теоретические) по каждой ТС и меняю приоритеты и %риска на ТС.
Какие-то ТС периодически выпиливаются из эксплуатации, добавляются новые.
Важно: эксель фактически использую как толстый клиент, т.е. на VBA там наговнякано изрядно.
В общем то все, чем мы занимаемся это curve fitting. Мы берем curve инструмента и вырезаем из него самые жирные куски. Чем плоха идея повырезать жирные куски из curve портфеля?
Конечно я не буду это делать бездумно, но немного оптимизации подключить хочется.
Выглядит именно так, что взять набор систем, набор параметров — и заоптимизировать их на истории по самое не могу.
по самые не могу я даже отдельные системы не оптимизирую.
Простой пример: сейчас весь январь трендовые системы пилит. У многих трейдеров январь в минусе. У меня трендовые системы составляют часть общего портфеля, я в плюсе. Но вопрос, а не мало/много ли у меня трендовых систем в портфеле, решен на уровне здравого смысла. Здравый смысл в таких решениях всегда выдает не самое оптимальное решение. Я хочу по меньшей мере посмотреть весь диапазон возможных вариантов и результатов.
Данные в экселе хранить, конечно, не вариант.
Ты и сам понимаешь.
С какими-нибудь знакомыми айтишниками в области обработки данных проконсультируйся.
PS Мне кажется, у тебя в таблице фактов полей мало.
Смотрел книжку «Статистика для трейдеров»? Там оч хорошая глава была, как трейды фиксить.
поля фактов ровно те, которые выдает стандартный отчет MT5.
Я даже не понимаю о чем речь, какие еще нужны исходные данные?
Посмотри главу 13 книжки Булашев. Статистика для трейдера.
Особенно 13.8. Отчет о сделках. И 13.9 потом.
Как-то мы пытались применить рэндом форест к ценовым рядам. Писал очень сильный парень, аспирант ВМК. Пока не применили оптимизацию вычислений и не переписали ядерные функции на Си, было ну очень тоскливо. Долго. До суток доходило.
SergeyJu, Эмм, чёт я запутался). Про эксель — я про эксель без VBA. VBA, конечно, расширяет сильно возможности, но хз, мне кажется питон с пандасом и юпитером покруче будет).
Про си, рэндом форест и крутого аспиранта вообще не понял) — это аргумент в пользу того, что питон плох? Или эксель? Если питон… — зачем там писать рэндом форест, в том числе на си) — там же все написано давно). Не пойму короч). Если есть готовые с си под капотом либы на питоне — надо их юзать — удобно и быстро, если нет — уже по ситуации. На готовых либах рэндом форест — ну зависит от гипер-параметров и объема данных, если я много данных заряжу — будет долго, сутки — столько ни разу не заряжал)).
Насчет Си в Питоне. Стандартный технический прием по ускорению счета тяжелых задач — переписать ядерные функции на более быстром языке. Чтобы те 5% кода, которые забирают 90% вычислений считались раз в 30 быстрее.
SergeyJu, Понял теперь.
Ну, не знаю зачем что-то самому писать, в смысле из каких-то стандартных вещей — тот же случайный лес из примера. Его можно найти в нескольких реализациях сейчас — и sklearn и пайторчи-тензорфлоу тоже его реализовали, вроде, да и ещё наверняка много где — вроде даже есть реализации, задействующие возможности GPU)). Мы только на учебе в учебных целей для лучшего понимания писали на питоне реализации чего-то такого)).
Питон, конечно, очень медленный для таких вещей, но так никто его и не использует — именно из-за производительности. И да, C в помощь если надо что-то тяжелое замутить. Пробовал импортировать простенькие вычисления на C в питон, но для боевых задач не приходилось использовать этот подход пока.